SOC 2 gets talked about like a certification — pass the audit, get the badge, put it on the website. That framing causes more preparation mistakes than almost anything else about the standard. SOC 2 is not a certification in the ISO sense; it is an attestation report, issued by an independent CPA firm, describing whether an organization’s controls meet a defined set of criteria over a period of time. That distinction — a report about controls observed over time, not a pass/fail exam — shapes almost everything about how a serious preparation effort should actually run.
What are the five Trust Services Criteria?
SOC 2 is built around the AICPA’s Trust Services Criteria, and an organization scopes its audit to whichever of the five categories are relevant to what it does. Security is mandatory in every SOC 2 audit — it covers protection against unauthorized access, both physical and logical, and is the foundation the other four build on. Availability addresses whether systems are available for operation as committed, relevant to any organization whose customers depend on uptime. Processing integrity covers whether system processing is complete, valid, accurate, and authorized — most relevant to organizations processing transactions or data on a customer’s behalf. Confidentiality addresses information designated as confidential being protected as agreed, distinct from the broader Privacy criterion in that it typically covers business and technical confidential information rather than personal data specifically. Privacy covers the collection, use, retention, and disposal of personal information in line with the organization’s stated privacy notice.
Most organizations scope their SOC 2 to Security plus one or two additional categories relevant to their actual service — a SaaS platform handling customer data commonly adds Availability and Confidentiality; one processing financial transactions on customers’ behalf is more likely to add Processing Integrity. Adding categories that don’t reflect what the organization actually does inflates audit scope and cost without adding meaningful assurance for the customers who will read the report.
What is the difference between Type I and Type II?
This is the distinction most often lost in casual conversation about SOC 2, and it matters enormously to what the report actually demonstrates. A Type I report assesses whether an organization’s controls are suitably designed as of a single point in time — a snapshot. A Type II report goes further: it assesses whether those controls operated effectively over a defined period, typically three to twelve months, based on evidence the auditor examines throughout that window.
The practical difference is significant. A Type I report can be produced relatively quickly once controls are documented and implemented, since it only requires showing the design is sound as of the audit date. A Type II report requires the controls to have actually been running, generating evidence, for the entire observation period before the audit can even begin — there is no way to accelerate a Type II by working harder in the final weeks, because the auditor needs evidence spanning months that have already passed. Most enterprise customers and procurement processes specifically ask for Type II, because a point-in-time design assessment says relatively little about whether controls hold up in ongoing operation. Organizations new to SOC 2 sometimes start with a Type I to establish a baseline and move to Type II the following cycle, but a Type I alone increasingly fails to satisfy sophisticated customers who know the difference.
What do auditors actually look for as evidence?
The recurring theme across every Trust Services Criteria category is that auditors want evidence a control operated, not a policy document asserting that it should. A written access-control policy stating that access reviews happen quarterly is not evidence; a record showing the quarterly reviews actually happened, on schedule, with documented outcomes, across the entire audit period, is. This is the single most common gap in first-time SOC 2 preparation — organizations that have reasonable policies on paper but no systematic evidence trail showing the policies were followed in practice.
Concretely, auditors typically examine: access provisioning and deprovisioning records (was access granted and revoked appropriately, and can you show it for departed employees specifically); change management logs (were changes to production systems reviewed and approved before deployment); vulnerability scanning and remediation timelines (are vulnerabilities found and fixed within a defined SLA, with evidence rather than assertion); incident response records (were incidents, even minor ones, logged, triaged, and resolved per the documented incident response plan, with evidence the plan was actually followed rather than existing only on paper); and vendor/third-party risk management (are the organization’s own vendors and SaaS integrations assessed for risk — a growing area of auditor scrutiny given how much data now flows through third-party SaaS platforms rather than systems the organization directly controls). Employee security awareness training completion and background-check records for personnel with sensitive access round out the typical evidence set.
Where does preparation actually break down?
The most common failure is starting the evidence trail too late. Because Type II requires evidence spanning the entire observation period, an organization that begins seriously implementing controls one month before the audit window closes simply cannot produce months of evidence retroactively — the fix is starting the audit period only once the underlying controls and evidence-generating processes are already running, not treating the audit start date as the trigger to begin compliance work.
A second common gap is treating SOC 2 as a one-time project rather than an operating discipline. Controls that were implemented carefully for the first audit cycle but allowed to lapse afterward — access reviews that happened diligently in month one and were quietly skipped by month nine — produce exactly the gap an auditor is trained to find, because Type II evidence spans the whole period, not just a sample near the end. A third is scope creep in the wrong direction: adding Trust Services Criteria categories that don’t map to the organization’s actual service, which expands the evidence burden without adding assurance customers actually need. And a fourth, increasingly common as environments sprawl across dozens of SaaS tools, is an incomplete inventory of systems and data in scope — an auditor will ask what systems process the data covered by the audit, and a gap between the documented system inventory and what’s actually in use (unsanctioned SaaS being a frequent culprit) surfaces as a control gap in itself, since you cannot evidence controls over systems you haven’t accounted for.
How should an organization prepare, practically?
Treat SOC 2 preparation as building an operating program, not assembling a document for a one-time exam. Start by scoping honestly — Security plus whichever additional criteria genuinely reflect the service being audited, not more. Implement the underlying controls and, critically, the mechanisms that generate ongoing evidence of those controls operating (automated logging of access changes, a ticketing system that timestamps vulnerability remediation, a documented and actually-followed change-management workflow) well before the audit observation period begins. Run the program for the full period the Type II report will cover, treating any lapse during that window as a real control failure rather than a minor slip, because the auditor will see the gap in the evidence either way. And build a continuous internal review — a lightweight version of the audit itself — so that gaps surface to the organization before they surface to the auditor.
Many organizations use a readiness assessment — a gap analysis run before the formal audit period begins, often by the same firm or a specialized consultant — specifically to catch these issues while there’s still time to fix the underlying process rather than discovering them mid-audit when the evidence window has already closed on a gap.
Frequently Asked Questions
Is SOC 2 a certification you pass or fail?
No. SOC 2 is an attestation report issued by an independent CPA firm describing whether an organization’s controls meet defined criteria — it’s a report about how controls performed, not a pass/fail exam. This distinction matters because it means preparation is about building an operating program with ongoing evidence, not passing a one-time test.
What is the difference between SOC 2 Type I and Type II?
A Type I report assesses whether controls are suitably designed as of a single point in time. A Type II report assesses whether those controls operated effectively over an extended period, typically three to twelve months, based on evidence collected throughout. Most enterprise customers specifically require Type II because it demonstrates sustained operation, not just design at one moment.
Which Trust Services Criteria does every SOC 2 audit need to include?
Security is mandatory in every SOC 2 audit. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and should be scoped based on what the organization’s service actually involves. Most organizations add one or two beyond Security rather than including all five.
Why can’t a Type II audit be rushed by working harder before the deadline?
Because a Type II report requires evidence that controls operated throughout the entire observation period, which can span three to twelve months. There is no way to retroactively generate evidence for months that have already passed without the underlying controls having actually been running and logging activity during that time.
What is the most common reason organizations fail SOC 2 preparation?
Starting the evidence-generating processes too late relative to the audit’s observation period, or letting controls that were carefully implemented at the start lapse by the end of the period. Since auditors examine evidence across the whole window rather than a snapshot, gaps anywhere in that period — not just near the audit date — surface as findings.