Learn · SOC Reports
SOC 2 Without the
Common Pitfalls
Most stalled SOC 2 examinations trace back to the same ten mistakes — made while scoping, during the review period, or in how the examination itself is handled. This is a plain-English field guide to each one: what it looks like, why it happens, and what to do instead.
None of these are exotic: every pitfall below shows up repeatedly in real engagements, and each has a boring, inexpensive fix — provided it is applied before fieldwork rather than during it.
Plain-English field guide · From real engagements · Last reviewed July 2026
Most SOC 2 problems are self-inflicted and predictable — scope chosen for optics, controls that start operating after the review period begins, evidence created retroactively, and surprises handled by hiding them. Avoiding the ten pitfalls below is largely what separates a smooth first examination from a stalled one. The context that makes them avoidable: SOC 2 is an examination, not a checklist — an independent licensed CPA firm tests your controls and issues an opinion (see what SOC 2 is and who can perform one). That structure explains almost everything on this list: the auditor reports what actually happened, cannot consult on fixes mid-examination, and samples evidence against timestamps. Teams that internalize those three facts early rarely hit the pitfalls below. Teams that treat SOC 2 as paperwork commonly hit several at once.
Phase 1 · Scoping
The Scoping Pitfalls (1–3)
Scoping decisions are made in the first weeks, often under sales pressure, and they compound: a bad scope is not a one-time mistake but a recurring annual cost. Three pitfalls dominate this phase.
Scoping every Trust Services Category “to look thorough”
What it looks like: a first-time report scoped to all five categories — Security plus Availability, Processing Integrity, Confidentiality, and Privacy — because a five-category report sounds more impressive on a sales call.
Why it happens: categories read like features on a pricing page. Teams commonly assume more categories signal more security, and nobody explains that each optional category adds criteria the auditor must test — this year and every year after.
Do instead: only Security (the common criteria) is required in every SOC 2. Add categories that match your actual customer commitments — uptime SLAs justify Availability; contractual processing promises justify Processing Integrity — and expand later if contracts demand it. Start from the Trust Services Criteria themselves, and pressure-test the choice in our SOC 2 simulator before committing.
A system boundary that misses the product customers actually buy
What it looks like: the report describes a corporate IT environment — laptops, HR onboarding, the office network — while the SaaS platform customers actually pay for sits outside the boundary. Or the boundary covers the product but never accounts for the cloud provider and other subservice organizations the system depends on.
Why it happens: boundary drawing is unfamiliar work, and it is tempting to draw the line around whatever is easiest to control rather than what customers rely on.
Do instead: define the system as the service your customers consume, then decide deliberately how each dependency is treated — carve-out or inclusive. A report scoped around the wrong system can be technically clean and commercially useless: procurement teams read the system description first.
Skipping readiness and going straight to the examination
What it looks like: engaging the CPA firm for a Type 2 with no gap assessment, so the first time anyone tests the controls is the auditor, during fieldwork.
Why it happens: schedule pressure, plus the assumption that the auditor will “tell us what to fix as we go.” Independence rules prevent exactly that — the examining auditor cannot design, implement, or remediate your controls.
Do instead: run a readiness assessment first. Gaps found in readiness are a to-do list; the same gaps found in fieldwork become exceptions in a report your customers read. Working through a structured SOC 2 compliance checklist before the auditor arrives is typically the cheapest money spent in the whole program.
Phase 2 · Operating
The Operating Pitfalls (4–7)
The Type 2 review period is where the examination actually happens: the report describes what operated during that window. The four pitfalls here share one root cause — treating the period as a formality rather than as the thing being reported on.
Starting the review period before controls actually operate
What it looks like: the period start date is picked off a sales deadline while half the controls are still being rolled out. The first months of the window have no access reviews and no formal change management — and the report has to say so.
Why it happens: the start date feels administrative. Teams think of the period as “when the audit is,” not as “what the audit reports on.”
Do instead: remember that the Type 2 opinion covers what actually happened during the window — not what was intended, planned, or nearly finished. Let controls run demonstrably, with evidence flowing and owners performing them, before the period opens. If a customer deadline cannot move, a Type 1 on a point-in-time basis is more honest than a Type 2 over a period the controls did not exist for.
Evidence created after the fact
What it looks like: quarterly access reviews “reconstructed” the week before fieldwork, approvals backfilled into tickets, a screenshot taken today standing in for a control that should have run months ago.
Why it happens: panic. When a gap is discovered late, the paper fix feels smaller than the honest disclosure.
Do instead: do not. Auditors sample against timestamps, system logs, and file metadata, and recreated artifacts commonly unravel under routine scrutiny — after which everything else you submit is examined harder. A missed review disclosed honestly is, at worst, an exception with a management response. Fabricated evidence is an integrity problem that damages the relationship with the auditor and can jeopardize the engagement itself. Generate evidence in the flow of work so there is never anything to recreate.
The platform on autopilot
What it looks like: the company buys a compliance automation platform — Vanta, Drata, Sprinto, or similar — connects the integrations, watches the dashboard turn green, and considers the program done. Nobody is actually performing the reviews the dashboard is monitoring.
Why it happens: dashboards are persuasive, and the tools are often sold as the whole journey rather than as part of it.
Do instead: use the platform for what it is genuinely good at — continuous monitoring, evidence collection, reminders — and recognize what it cannot do. A control is a decision plus a repeated human practice; software can observe it but not perform it. If nobody owns the quarterly access review, the tool will faithfully collect evidence that it is not happening. Tools help; ownership decides.
Single-owner compliance
What it looks like: the entire program lives in one person’s head. They run the reviews, hold the platform login, and answer every auditor question — then they resign mid-period, controls quietly stop, and nobody notices until fieldwork.
Why it happens: small teams, and compliance treated as a project with an end date rather than an operating function.
Do instead: assign a named owner to every control — not one owner for the whole framework — document how each control is performed, and designate a deputy for the program itself. The review period does not pause for resignations, leave, or reorgs.
Phase 3 · Examination & After
The Examination Pitfalls (8–10)
Fieldwork, and the months after issuance, have their own failure modes — mostly about candor, claims, and calendars.
Hiding exceptions — or treating them as catastrophes
What it looks like: two versions of the same mistake. One team discovers a failed control mid-period and quietly hopes the auditor’s sampling misses it. Another receives a draft report with a single exception and treats it as a disaster to be argued away.
Why it happens: both stem from the same misreading — that SOC 2 is pass/fail and any exception means failure.
Do instead: understand how opinions and exceptions actually work. Reports with a few exceptions, clear remediation, and a written management response are routine and generally accepted by customers. Concealment is the real catastrophe: discovered, it can push the auditor toward a qualified opinion and does lasting damage to trust. Disclose early, remediate, respond in writing.
Overclaiming mid-journey
What it looks like: a “SOC 2 Certified” badge on the website while the first review period is still running, or sales telling prospects “we have SOC 2” when what exists is a readiness plan and a platform subscription.
Why it happens: pipeline pressure, plus genuine confusion about what each stage means.
Do instead: assume procurement teams will verify — they ask for the report and check the period dates and the CPA firm. (And “certified” is wrong on its own terms: SOC 2 is an attestation; there is no certificate.) Precise language holds up and even builds trust — there is a whole script for what to tell customers mid-journey.
Letting the report lapse
What it looks like: the report is issued, everyone exhales, and nobody schedules the next review period. Months later a renewal security review asks for a current report, and the gap since the period ended keeps widening with nothing planned.
Why it happens: post-examination fatigue, and no single owner of the compliance calendar.
Do instead: schedule the next period at issuance — back-to-back periods with no gap are the cadence customers expect. A short gap between report periods can be covered with a bridge letter, but a bridge letter extends a current report; it cannot resurrect a lapsed program. A stale report reopens every security review you thought you had closed.
The anti-pitfall playbook, in five lines
- Scope to commitments: Security plus only the categories your contracts actually promise.
- Run readiness before the examination, and let controls operate demonstrably before the review period opens.
- Generate evidence in the flow of work — a named owner per control, with the platform as instrumentation rather than a substitute.
- Disclose problems early; handle exceptions with remediation and a written management response, never with silence.
- Claim precisely while in progress, and schedule the next review period the day the report is issued.
If you would rather not learn these the hard way: Tranquility Cybersecurity runs the readiness, remediation, and evidence phases and coordinates the examination itself through empanelled, independent licensed CPA firms — with 500+ audits delivered across 250+ clients, most of this list is something we have prevented many times over. See our SOC 2 services for how an engagement is structured.
SOC 2 Pitfalls — Common Questions
Pass/fail myths, fieldwork surprises, and what platforms can and cannot do.
What are the most common SOC 2 mistakes?
The ones that recur across engagements: scoping every Trust Services Category for optics, drawing the system boundary around the wrong system, skipping readiness, starting the Type 2 review period before controls operate, recreating evidence after the fact, running a compliance platform on autopilot with no control owners, concentrating the whole program in one person, hiding known failures from the auditor, claiming “SOC 2 certified” before a report exists, and letting the report lapse with no next period scheduled. Almost all of them are process and ownership failures rather than technical ones.
Can you fail a SOC 2 audit?
Not in a pass/fail sense. The auditor issues an opinion — unqualified, qualified, adverse, or a disclaimer — and lists any exceptions found in testing. A report with some exceptions and an unqualified opinion is common and generally accepted by customers. What teams experience as “failing” is usually one of two things: an examination that stalls because controls or evidence were not ready, or a report so heavily qualified that customers decline to rely on it. Both are largely preventable with readiness work before the examination begins.
What happens if the auditor finds a gap during fieldwork?
It gets documented as what it is — a deficiency in design, or an exception in operation for the period examined. The auditor cannot consult on the fix or quietly overlook the finding; independence rules prohibit exactly that. You can remediate going forward and include a management response in the report, but the finding still reflects the period in which it occurred. This is why gaps are so much cheaper to find in a readiness assessment, where the same discovery is simply a to-do item instead of a published exception.
Should we fix issues before or during the review period?
Before, wherever possible. An issue fixed before the period opens typically never appears in the report at all. An issue fixed mid-period may still surface as an exception for the portion of the window when the control was not operating. An issue the auditor discovers during fieldwork will be documented. The cost of the same problem rises at each stage — which is the practical argument for readiness work, and for not opening the review period until controls are genuinely running.
Is a compliance platform enough to get SOC 2?
No — and that is not a criticism of the platforms. Tools like Vanta, Drata, and Sprinto automate evidence collection and monitoring, which removes real work. But the examination tests whether controls operated: whether reviews happened, approvals were made, and incidents were handled. Those are human practices the platform can observe but not perform. Every control needs a named owner; a green dashboard with no owners behind it commonly turns into failed tests during fieldwork.
How do we avoid exceptions in our SOC 2 report?
You cannot guarantee zero, and chasing zero is the wrong goal. You can shorten the odds considerably: scope narrowly, run a readiness assessment, let controls operate before the review period opens, generate evidence in the normal flow of work, assign a named owner to every control, and spot-check control performance internally during the period rather than waiting for fieldwork. When something does fail, disclose it, fix it, and document a management response — a handful of transparently handled exceptions is a normal feature of real reports.
What is the single most expensive SOC 2 pitfall?
Arguably retroactive evidence. Most other pitfalls cost time or produce survivable exceptions; fabricated or backdated artifacts convert an ordinary gap into an integrity problem. Auditors sample against timestamps and system metadata, so recreated evidence commonly unravels — and once it does, every other artifact attracts deeper scrutiny, fieldwork extends, and the auditor relationship may not recover. A close second is starting the review period before controls operate, which commonly forces the period to be shifted or the first report to carry avoidable exceptions.
Related reading: the Learn hub, what SOC 2 is, the SOC 2 compliance checklist, opinions & exceptions, who can perform a SOC 2 audit, and SOC 2 services. More terms in the compliance glossary.
Written By Expert Auditors
Get in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours