SOC 2 Compliance
SOC 2 is an attestation, issued by an independent accountant under the AICPA's standards, that a service company's controls over security — and optionally availability, processing integrity, confidentiality and privacy — are designed properly (Type I) and operated effectively over a period (Type II). It is the report a bank's procurement team asks a fintech vendor for before any contract, and one of the first documents in a technology company's data room.
- Also known as
- SOC 2, SOC 2 Type II, Service Organization Control 2
- Used at
- vendor onboarding by banks and enterprises, and technology due diligence in any acquisition of a software or fintech company
- Binding
- not by law — a SOC 2 is a voluntary attestation, but customers' contracts make it a condition, and its absence ends sales conversations
- Typical scope
- the five Trust Services Criteria — security is mandatory, the other four optional; a Type II report covers an observation period of 6–12 months
- Typical cost and time
- $30,000–150,000 for the audit and the tooling, 3–6 months to readiness for a first Type I, then the observation period for a Type II
- Parties
- the service organisation, its auditor (a CPA firm), and the customers and acquirers who rely on the report
How SOC 2 works in practice
A SOC 2 is not a certificate but a report. The company defines the system in scope — the platform its customers use — and the criteria it will be assessed against; the auditor examines the controls the company says it operates: access reviews, change management, encryption, monitoring, incident response, vendor management, and how it hires and offboards staff. A Type I report says the controls were suitably designed on a date. A Type II says they operated effectively over the period, with the auditor's tests and any exceptions listed. Customers read the exceptions.
For a fintech selling to banks the report is table stakes: without it, the bank's third-party risk team cannot approve the vendor, and with a report full of exceptions it will not. The report also does something for the company itself. Preparing for it forces the controls to exist — the access review that was going to happen, the change process that was in someone's head — and the observation period proves they kept happening.
In an acquisition the report is read differently. A buyer's technology diligence uses the SOC 2 to skip the questions the auditor already answered and to focus on what is out of scope, what the exceptions say, and whether the controls will survive integration. A target with no SOC 2 costs the buyer a full security assessment and a year of remediation before its customers can be sold to.
Example
A fintech selling reconciliation software has a Type II report covering security and availability over twelve months, with two exceptions: three departed contractors whose access was removed after 30 days rather than the policy's 5, and one production change deployed without a recorded approval. A bank's procurement team accepts the report with a remediation letter. A year later, an acquirer's diligence reads the same report, checks that the following year's report closed both exceptions, and cuts its planned security assessment from eight weeks to two. A rival target with no report, whose founders "never got round to it", costs the same acquirer a $180,000 external assessment, and the sale to the bank customers waits nine months for a first Type II.
Common mistakes
- Announcing "SOC 2 certified" — there is no certification, only a report with a scope and a period, and customers who know the difference. - Scoping the report to the marketing site or a subsystem so the audit is easy, then being asked why the payments platform is not in it. - A Type I that never becomes a Type II. - Controls that exist for the observation period and lapse when the auditor leaves. - In diligence, taking the report's existence as the answer instead of reading the exceptions and the scope.