What a SOC 2 Type II audit actually tests (and what it doesn't)

SOC 2 is the single most commonly requested attestation in the SaaS and financial services world. It is also one of the most commonly misunderstood. This article is a plain-language walk through what a SOC 2 Type II audit actually tests, how it is different from Type I, what the five Trust Services Criteria mean in practice, and which findings we see over and over again on first-time engagements.

SOC 2 in one paragraph

SOC 2 is a reporting framework published by the American Institute of Certified Public Accountants (AICPA). It is not a certification, not a regulatory requirement in any jurisdiction, and not something you can self-declare. A SOC 2 report is issued by an independent CPA firm that examines your controls against a set of criteria known as the Trust Services Criteria, and issues an opinion on whether those controls were in place (Type I) or operated effectively over a period of time (Type II). The report is often shared under NDA with customers, partners, and regulators who want independent assurance about how you operate.

Type I vs. Type II: the distinction that actually matters

A Type I report says that as of a specific date, the controls described in management's assertion were designed appropriately. It is a point-in-time statement. It does not say the controls worked over time. A Type II report says that over a specified observation period (usually six or twelve months), the controls not only existed but operated effectively. The observation period is the key difference. If you have never done a SOC 2 before, a Type I is a reasonable first step. But sophisticated customers ask for Type II because it is the only report that tells them your controls actually work, not just that they exist on paper.

The five Trust Services Criteria, in plain language

The criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory — every SOC 2 report includes the Security criterion, which is often called the Common Criteria. It covers access control, change management, vulnerability management, incident response, and the organizational controls that support all of these. Availability covers whether your systems are available when they are supposed to be available — think service-level commitments and business continuity. Processing Integrity covers whether your systems process data completely, accurately, and in a timely manner — this criterion matters most to firms that process transactions. Confidentiality covers how you protect data designated as confidential — think customer data, partner data, and contractual obligations. Privacy covers how you handle personal information — it overlaps with GDPR and similar privacy regimes but is not a substitute for them. Most first-time SOC 2 reports cover only Security. Organizations add other criteria when their customers ask for them.

What auditors actually look at

A SOC 2 auditor does three things. First, they understand your control environment: they walk through your processes, interview your people, and review your documentation. Second, they test design: they evaluate whether the controls you describe would work if they were operating. Third, and this is where Type II differs from Type I, they test operating effectiveness: they sample evidence across the observation period and verify that the controls were actually operating. Sampling is the part most first-time subjects underestimate. For a control that is supposed to happen weekly, an auditor might sample five or six weeks out of the observation period. For a control that is supposed to happen on every access grant, they might sample twenty-five access grants. If even one of the samples is missing — if one weekly meeting did not happen, if one access grant was not properly documented — the finding goes on the report.

The findings we see most often

On first-time engagements, a small set of findings accounts for the majority of what ends up on the report. Access review cadence is probably the most common: the organization has an access review policy, but for two of the six quarters in the observation period, the review was late or incomplete. Change management documentation comes second: changes were made, but the pre-change risk review was not documented. Third is vendor risk management: a new vendor was onboarded without the standard security review being completed. Fourth is terminated-user access removal: a departing employee retained access to a system for more than the policy window. None of these are sophisticated attacks; they are process discipline issues. They are also the easiest to fix, if you address them before the audit rather than during it.

What a SOC 2 report is not

A SOC 2 report is not a security certification. It is a point-in-time or observation-period opinion from an independent firm. It is not a regulatory attestation in any jurisdiction; no regulator recognizes it as meeting their own requirements. It is not a substitute for HIPAA, PCI-DSS, ISO 27001, or any other framework. It is not a guarantee of anything — it is a reasonable assurance opinion based on the evidence the auditor saw. Treat it as what it is: a well-understood shared vocabulary for discussing control maturity with customers who are doing vendor risk management at scale.

Tags