SOC 2 compliance,
explained plainly

SOC 2 is an attestation report on the controls a service organization uses to protect customer data. It is part of the AICPA’s System and Organization Controls framework and is performed under the attestation standard SSAE 18. The work is carried out by a licensed CPA firm, and the deliverable is a report containing the auditor’s opinion on whether your controls meet the criteria you are reporting against.

The single most important thing to understand is that SOC 2 is not a certification. There is no "SOC 2 certificate" and no body that certifies you. You are not "SOC 2 certified" — you have a SOC 2 report. The distinction is not pedantry: it changes what you can claim, what a customer is actually reviewing, and how the whole process is structured. An auditor is not stamping a pass; they are forming and writing down a professional opinion about your system.

Because it is a report rather than a badge, the contents matter. A SOC 2 report includes a description of your system, the controls you have in place, the tests the auditor performed, the results of those tests, and the opinion they reached. A prospect’s security team reads the report; they do not just check a box that says you have one.

A SOC 2 examination comes in two forms, and the difference is about time. A Type I report assesses whether your controls are suitably designed at a single point in time — a snapshot. The auditor looks at your controls on a given date and forms an opinion on whether, as designed, they would meet the criteria. It says nothing about whether those controls actually ran day after day.

A Type II report assesses whether your controls operated effectively over a period of time: an observation window, typically somewhere between three and twelve months. Instead of a snapshot, the auditor samples evidence across the whole window to test that each control did what it was supposed to, consistently, throughout. This is a meaningfully harder thing to demonstrate, because it requires the control to have been running, and the evidence to have been kept, for months before the auditor ever looks.

In practice, Type II is what customers actually want. A Type I tells a buyer your controls looked right on one day; a Type II tells them your controls worked over a real period. Many teams start with a Type I to get something in hand quickly, then move to a Type II once the controls have a track record behind them — but the destination almost everyone is asked for is the Type II.

SOC 2 is evaluated against the Trust Services Criteria (TSC), a set of criteria maintained by the AICPA and built on the COSO internal-control framework. There are five categories, and a common misconception is that you must address all of them. You do not. You choose which categories are in scope based on the commitments you make to customers.

Security (also called the Common Criteria) is always required. It is the foundation of every SOC 2 report and covers protecting the system against unauthorized access, disclosure and damage. On top of Security, you add any of four optional categories: Availability (the system is available for operation and use as committed), Processing Integrity (processing is complete, valid, accurate, timely and authorized), Confidentiality (information designated as confidential is protected) and Privacy (personal information is collected, used, retained and disposed of in line with your commitments).

Adding categories is not free — each one brings its own criteria, its own controls and its own evidence to keep current. The right scope is the smallest set that honestly reflects what you promise customers. A SaaS product with an uptime commitment in its contracts has a clear reason to include Availability; a team that does not handle personal data on behalf of customers usually has no reason to take on Privacy. Picking criteria you cannot back up only makes the examination harder.

SOC 2 is rarely pursued for its own sake. Most teams start because a customer asked — it surfaces in a security review, a procurement questionnaire or a vendor-risk assessment, usually from a US-based buyer. SOC 2 originated in the United States and has become the de-facto trust standard for SaaS and cloud vendors selling there. If you sell software to American companies of any size, the request tends to arrive sooner or later, and often blocks a deal until you can answer it.

It works because it lets a buyer outsource the question they cannot answer themselves: "can I trust this vendor with our data?" Rather than auditing you directly or sending an endless questionnaire, they ask for a SOC 2 report from an independent CPA firm and read the opinion. For the vendor, a report turns "fill out our 200-question security review" into "here is our SOC 2, under NDA" — which is why teams that win enough enterprise deals eventually treat it as the price of entry.

The practical test for whether you need it is simple: are you losing or stalling deals because a customer wants independent assurance about your security and you cannot give it? In the US market, SOC 2 is usually the most widely recognized answer, and most of the work of getting there is the work of running security well and keeping the evidence.

The first real decisions in a SOC 2 project are which Trust Services Criteria you report against and what "the system" actually is. The system description (a required part of the report) defines the boundary: which product, which infrastructure, which supporting processes and which people the examination covers. Draw it too wide and you have signed up to evidence everything at once; draw it too narrow and the report will not cover what your customer is asking about.

Most teams scope SOC 2 around the product their customers buy and the infrastructure and processes that run it, then choose criteria to match the promises they make about that product. The system description is written plainly enough that a reader of the report (a prospect’s security reviewer) can tell exactly what was and was not examined.

For a Type II report, the centre of gravity is the observation period — the window over which the auditor tests that your controls operated effectively. It is commonly three to twelve months; a first Type II often uses a shorter window to produce a report sooner, with later reports covering a full year. Whatever its length, the period has a hard implication: the evidence has to exist for the entire window, gathered as you went, not assembled the week before the auditor arrives.

This is where SOC 2 lives or dies operationally. The auditor will sample across the period (access reviews that should have happened quarterly, change approvals on deployments, incident records, vendor reviews) and ask for the proof that each control ran on the dates it was meant to. A control that exists in policy but has no evidence trail across the period is, for the purposes of a Type II, a control that did not operate. Teams that keep evidence flowing continuously sail through; teams that try to reconstruct ten months of access reviews after the fact do not.

The other consequence is timing. Because a Type II looks backward across a real period, you cannot start the examination and have a clean report the next week — the period has to have already happened with the controls running. Planning the observation window, and making sure the controls are genuinely operating from its start date, is most of what preparing for a Type II actually involves.

A SOC 2 examination must be performed by an independent, licensed CPA firm — that independence is what gives the report its weight, and it is why no one can self-certify SOC 2. The firm plans the engagement, reviews your system description, tests your controls against the criteria in scope, and issues the report with their opinion. For a Type II, that testing means sampling evidence across the observation period rather than checking a single day.

The opinion at the front of the report is the part a reader looks for first. An unqualified opinion means the auditor found your controls suitably designed and, for a Type II, operating effectively across the period, with no material exceptions. A qualified opinion means they found one or more exceptions significant enough to call out: a control that did not operate as described, a gap in the evidence, a criterion not fully met. A report can still be useful with a qualified opinion, but the qualification tells the reader exactly where to look, so it is worth understanding any exceptions before the report is finalized.

Choosing the firm matters more than its price tag suggests. A firm that knows software and cloud infrastructure will ask for evidence in a form your team can actually produce; one that does not will turn the engagement into a translation exercise. Either way, the bulk of the effort is on your side — the firm tests what you give them, so the quality and availability of your evidence sets the tone of the whole examination.

A SOC 2 report covers a specific period, and then that period ends. Because customers want current assurance, SOC 2 is not a one-time exercise: most teams produce a new Type II report each year, covering the next observation period, so there is always a recent report to share. The work that earned the first report (keeping access reviews on cadence, change approvals recorded, incidents logged, vendor reviews done) is the same work that produces every report after it. Teams that treat the first examination as a sprint feel the cost again every year; teams that build the controls into how they already operate do not.

Between the end of one report’s period and the start of the next, there is a gap, and customers asking for current assurance need something to cover it. That is what a bridge letter (sometimes called a gap letter) is for: a short statement, usually from your management, affirming that the controls described in the most recent report have continued to operate, with no material changes, through the gap. It is not a substitute for the report and it does not carry the auditor’s opinion, but it lets you answer a security review honestly in the months between examinations.

There is no single price for SOC 2, because most of the cost is your own effort rather than a line item. The CPA firm charges a fee for the examination, scaled to the criteria in scope, the size of your system and whether it is a Type I or a Type II. That fee is usually the smaller part, and a Type II costs more than a Type I because there is more to test across a period.

The larger cost is building and running the controls and keeping the evidence current across the whole observation period: defining the system, choosing criteria, writing policies, operating the controls month after month, and gathering the proof an auditor will sample. Teams that assemble this from spreadsheets and shared drives pay for it again at every annual report, in the time it takes to reconstruct evidence that was never kept in one place.

Two levers move total cost more than the firm’s fee. The first is scope: every extra Trust Services Criteria you add brings more controls and more evidence, so reporting only against the criteria your commitments actually require keeps the work proportionate. The second is maintaining the controls continuously rather than rebuilding the evidence before each year’s examination — which is the difference between a report that is mostly administrative and one that is a scramble.