The same handful of issues show up in almost every first-time SOC 2 audit. If you know what they are before your auditor starts sampling, you can close most of them in the readiness phase instead of finding out about them in a findings letter. Below are the soc 2 common findings that recur most often across early-stage SaaS companies, ranked roughly by how frequently auditors cite them, with real examples of what triggers each one and what it actually costs in delay.
Why This List Matters Before You Even Start Readiness
Every one of these findings traces back to the same root cause: a control that exists informally but was never written down, enforced technically, or evidenced consistently. Auditors don't expect perfection. They expect that what you say you do matches what your systems and records show you actually did. A finding doesn't necessarily fail your audit — most are manageable — but each one adds back-and-forth with your auditor, and back-and-forth adds weeks.
Knowing this list in advance changes how you spend your readiness period. Instead of guessing where the gaps might be, you check these ten areas first, because statistically, that's where they are.
The 10 Findings, Ranked by Frequency
1. MFA enforced inconsistently across systems
Multi-factor authentication is often enabled on the identity provider but left optional on the AWS console, or required for engineers but not for customer success staff with admin access to the product. Auditors check enforcement across every system in scope, not just the ones a company remembers to mention. "We encourage it" doesn't satisfy a control that requires it be technically required.
2. Former employees or contractors with active access
This is the single most common access control finding. A contractor who finished a project months ago still has a live login. A customer success manager who left the company still has admin rights to the helpdesk. These surface the moment an auditor compares your active account list against your HR roster — which is one of the first things they do.
3. Shared administrative accounts
When three engineers all use the same "admin" login, there's no way to trace a given action back to an individual. Auditors require access to be attributable to a specific person, which means shared accounts have to be replaced with individual ones before the audit, not during it.
4. No documented access review
Many companies informally check who has access when someone leaves, but have never run a formal, dated, documented review. An undocumented review is treated the same as no review at all — the absence of a record is itself the finding, even if the underlying access was fine.
5. Branch protection not enforced on production changes
A written policy that says all changes require peer review means nothing to an auditor if developers can still merge their own pull requests or push directly to main. This is a frequent gap because the policy and the Git configuration drift apart — the policy document says one thing, the repository settings allow another.
6. Emergency changes with no retroactive documentation
A 2 a.m. hotfix that bypasses the normal approval workflow is allowed under SOC 2 — but only if it's reviewed and documented within 24 to 48 hours after the fact. Auditors who sample a change period and find an undocumented emergency deploy will flag it as a gap in the change record, even if the fix itself was sound.
7. Infrastructure changes made outside the change process
Console changes made directly in AWS or GCP — a security group opened, an IAM policy edited — often bypass the pull request workflow entirely because they weren't thought of as "code." If those changes affect production and aren't tracked anywhere, the change management control has a hole in it.
8. Missing or incomplete employee training records
SOC 2 requires evidence that employees completed security awareness training, not just a policy stating they should. The common gap: a new hire joins mid-period and never completes training, or completion isn't tracked anywhere auditable. Auditors will check this for everyone employed during the audit window, not just the current team.
9. No vendor security review for critical third parties
If a critical vendor was added or changed during the audit period, auditors may ask what due diligence was done before granting them access to your data. Companies that don't maintain any record of vendor risk assessment — even an informal one — struggle to answer this.
10. Logs or monitoring not actually reviewed
Having CloudTrail enabled and having someone actually look at the alerts it generates are two different controls. A common finding is monitoring that's technically switched on but produces no evidence anyone ever reviewed an alert or acted on one.
What Each Finding Actually Costs You in Time and Audit Delay
None of these findings are usually fatal to a SOC 2 report, but each one adds a cycle of auditor follow-up, and follow-up cycles are where timelines slip. A typical pattern:
| Finding category | Typical fix time | Added audit delay if found during fieldwork |
|---|---|---|
| Stale access / former employees | 1–3 days to revoke | 1–2 weeks (re-sampling required) |
| Shared admin accounts | 1–2 weeks to split into individual accounts | 2–4 weeks if discovered late |
| No documented access review | Same day once a template exists | 1 week minimum — can't be backfilled convincingly |
| Branch protection gaps | Under a day to configure | 1–2 weeks of re-testing sampled changes |
| Missing training records | Days, if the curriculum already exists | 1 week to re-verify completion for the full period |
The pattern across all five: fixing the underlying issue is almost always fast. What's slow is proving, retroactively, that it was fixed in time to cover the audit period — which for a Type 2 report, you often can't do. That's why these are worth catching in readiness, not remediation.
How SocBridge's Readiness Process Is Built to Prevent Each One
These ten findings are common enough that a readiness process can be built specifically around them rather than treating every company as a blank slate. SocBridge's compliance leads start every engagement with a gap assessment that checks these exact areas — access inventory against your HR roster, MFA enforcement settings system by system, branch protection configuration, and training completion records — before an auditor ever sees your environment.
The IronFort platform, set up as part of the engagement, automates the evidence collection that catches most of these findings before they become findings: it timestamps attestations, tracks training completion automatically, and gives your auditor read-only access to a single system instead of a folder of screenshots assembled the week before fieldwork. Technical gaps — unenforced MFA, missing branch protection, console changes outside your IaC workflow — are handled by cloud-certified architects as part of the control implementation phase, not left for your engineering team to discover during the audit.
If you want more detail on two of the categories above, the access control gaps are covered in depth in our incident response plan template, and the change management findings — branch protection, emergency changes, infrastructure-as-code — are broken down further in how B2B SaaS companies prepare for SOC 2. If you're earlier in the process and still deciding between Type 1 and Type 2, that choice affects how many of these findings matter to you in the first place — see how long SOC 2 takes for startups.
The AICPA's own guidance on the Trust Services Criteria is the authoritative source for what these controls are meant to achieve, if you want to read the standard directly rather than take a summary of it. NIST's access control guidance is also a useful reference for the technical side of least-privilege design, independent of SOC 2 specifically.
The common thread across all ten findings is that none of them require new technology to fix — they require someone to check, document, and enforce consistently what most companies already believe they're doing. That's the part a done-for-you process is built to catch before the auditor does.