# 5 Common SOC 2 Compliance Mistakes (and How to Avoid Them) Source: https://scadable.com/blog/common-soc2-mistakes Published: 2026-07-12 --- **Most SOC 2 mistakes are not clerical. They are decisions made in the first few weeks, before anyone has evidence to correct course: starting the audit clock too early, scoping too broadly, writing policy that does not match practice, treating evidence as a scramble instead of a byproduct, and picking a vendor on price instead of on who actually does the work.** Every one of these is avoidable, and every one of them gets more expensive the later it is caught. None of this is about SOC 2 being unusually hard. The [SOC 2 framework](/frameworks/soc-2) itself is a known quantity: an independent auditor checks your controls against the AICPA Trust Services Criteria and writes up what they find. The mistakes below are about how teams run the project around it, and they repeat across companies with no connection to each other, because the incentives that produce them are the same everywhere: a deal is stuck behind the report, someone wants it done fast, and the fastest-looking path is usually the one that costs the most later. ## Mistake 1: Starting the observation window before controls are actually stable A Type II report does not examine whether your controls are well designed, it examines whether they operated effectively over an observation window, typically three to twelve months. Teams that are eager to get moving start that clock as soon as a control exists on paper, before it has actually been running long enough to be reliable. The result is months of evidence that faithfully documents the gaps nobody had fixed yet, because the window was already running while the fixes were still in progress. This happens because the pressure is almost always external, a deal or a renewal with a deadline attached, and starting the clock feels like progress even when the underlying work is not ready. The fix is to treat the observation window as something you start on purpose, not something you start by default. Get access reviews, vulnerability management, and change control actually running first, let them settle into a real operating rhythm, and only then start the window that the audit will examine. For the mechanics of what Type I and Type II each actually check and when a Type I makes sense as an interim step, see [SOC 2 Type 1 vs Type 2](/blog/soc2-type1-vs-type2). ## Mistake 2: Treating scope as a formality instead of a real decision Scope defines every system, process, and vendor the audit will examine, and it is decided in the first meeting, usually fast, usually generously. The default instinct is to draw a wide circle around anything that could plausibly touch customer data, because narrowing it later feels risky. But every system pulled into scope needs its own controls, its own evidence, and its own place in the audit narrative. A wider scope does not make the report stronger, it just makes everything downstream slower and more expensive to prove. The better approach is to ask, system by system, whether it actually needs to be in scope for what this report is meant to demonstrate, not whether it theoretically could be. A staging environment with no real customer data, an internal tool with no external access, a legacy service scheduled for retirement, these are common candidates for exclusion that teams pull in anyway out of caution. Getting scope right also depends on being honest about whether you need a SOC 2 report at all yet, and for what; [do you need SOC 2](/blog/do-you-need-soc2) is the decision framework worth running before scope conversations start. ## Mistake 3: Writing policies that do not match what the team actually does Policy documents are easy to write and easy to get wrong in a specific way: written to satisfy a checklist item rather than to describe the team's actual day-to-day behavior. An access review policy that says reviews happen quarterly, when they have never actually happened on that cadence, is a liability, not an asset. An auditor's job is to test whether reality matches the policy, and a mismatch is a finding regardless of how well the document reads. This mistake happens because policies often get written by whoever is closest to the audit deadline, working from a template, without checking with the people who would actually have to follow the policy day to day. The fix is unglamorous: write down what the team actually does, close the gap between that and what good practice requires, and only then formalize it as policy. A policy adopted after the practice is real holds up. A policy written first and imposed on the team rarely survives contact with an audit sample. ## Mistake 4: Letting evidence collection be a manual, pre-audit scramble This is the one that eats the most time and causes the most last-minute stress. Teams treat evidence as something to gather in the weeks before the audit; a folder of screenshots, a spreadsheet of who approved what, exports pulled together under deadline pressure. The problem is that a Type II report examines a period of months, and evidence assembled after the fact cannot prove what happened continuously during that period, only what someone remembered to document. The fix is to make evidence a byproduct of how the system runs, not a separate task bolted on before the audit. Access approvals, vulnerability scans, deployment logs, and vendor reviews should generate their own record automatically, as they happen, so nothing has to be reconstructed later. Teams that get this right stop dreading the audit because there is nothing to scramble for, the evidence has been accumulating the whole time. [How to manage SOC 2 without a pile of manual templates](/blog/soc2-without-manual-templates) goes deeper into what continuous evidence collection actually looks like in practice. ## Mistake 5: Choosing a vendor on price or speed instead of who does the actual work This is the mistake underneath most of the others, because it is usually the reason they happen in the first place. Companies shop for a SOC 2 vendor the way they would shop for any software, comparing price and promised timelines, without asking the more important question: does this vendor actually implement the missing controls, or does it just show you a dashboard of what is missing and leave you to fix it. The two look similar in a sales call and are completely different in practice six months in. A tool that flags gaps but does not close them shifts all the real work back onto a team that usually does not have the spare engineering time to do it, which is exactly why the abandoned-vendor pattern is so common: a company signs up, gets a checklist, stalls on actually implementing the controls, and starts over with someone else a few months later having lost the time and the money. The question worth asking before signing anything is concrete: when a control is missing, does this vendor build it, or does it just tell you that it is missing. ## Frequently asked questions **What is the most common SOC 2 mistake?** Starting the Type II observation window before the underlying controls are actually stable. Teams start the clock on the pitch deck timeline instead of the real one, and the audit evidence ends up documenting the same gaps for months instead of proving the controls worked. **Why do companies end up in scope for systems that do not need to be?** Because scope gets treated as a checkbox instead of a real decision early on. Whatever touches customer data by default gets pulled in, without asking whether it needs to be there. Every extra system in scope means more controls to implement, more evidence to collect, and more places an auditor can find a gap. **Why does an audit expose a gap between policy and practice?** Because the policy document was written to satisfy the audit checklist, not to describe what the team actually does day to day. An auditor tests whether reality matches the policy, not whether the policy reads well, and a policy that was never followed is worse than no policy at all because it is a documented commitment you broke. **Why is evidence collection the hardest part of SOC 2?** Because most teams treat it as a manual, pre-audit scramble instead of a continuous byproduct of how the system runs. Screenshots and exports gathered the week before the audit prove almost nothing about the months in between, which is exactly what a Type II report is supposed to cover. **Why do companies abandon their SOC 2 vendor partway through?** Because the vendor was chosen on price or speed promises without checking whether it does implementation work or just hands over a checklist and a dashboard. A tool that shows you the gap and leaves you to close it is not solving the problem you hired it to solve, and teams eventually notice and start over with someone who does the actual work. Last reviewed: July 12, 2026. ## Where Scadable fits Every mistake above comes from the same root cause: treating SOC 2 as a document exercise instead of an operational one. A report that is written and then run, rather than run and then written up, does not fall into any of these traps, because scope, policy, and evidence all trace back to what is actually happening in the system. That is the concierge, implementation-first model Scadable runs: it does not hand you a gap list and wish you luck, it implements the missing controls, keeps the evidence current as a byproduct of the work, and gets the scope and the timeline right before the clock starts. [Book a call](https://cal.com/rahbaral/quick-chat) to talk through where your SOC 2 project actually stands.