---
title: "SOC 2 Compliance"
url: "https://mahouse.world/glossary/soc-2-compliance"
type: "glossary term"
topic: "Compliance"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-09-09"
---

# 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

## Key facts

- **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.

## Related terms

- [Audit Trail](https://mahouse.world/glossary/audit-trail.md)
- [PCI DSS](https://mahouse.world/glossary/pci-dss.md)
- [RegTech](https://mahouse.world/glossary/regtech.md)
- [Legal Due Diligence](https://mahouse.world/glossary/legal-due-diligence.md)
- [API](https://mahouse.world/glossary/api.md)
- [Hardware Security Module](https://mahouse.world/glossary/hardware-security-module.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov