What SOC 2 Actually Proves (And What It Doesn't)
A vendor telling you they are 'SOC 2 certified' has already told you something worth noticing — SOC 2 is not a certification, and the distinction is not pedantry.
SOC 2 gets treated in vendor conversations as a pass/fail credential — "are you SOC 2?" — when it is actually a detailed, scoped report whose value depends entirely on what you do with it rather than whether it exists. This is a companion piece to our guide on data security for enterprise software projects.
What SOC 2 actually is
SOC 2 (System and Organization Controls 2) is a reporting framework developed under American Institute of CPAs (AICPA) standards. A licensed CPA firm audits a service organisation's controls against the AICPA's Trust Services Criteria — security, availability, processing integrity, confidentiality, and privacy — and produces a report describing what it found.
The first thing worth being precise about: SOC 2 is an attestation, not a certification. There is no pass/fail badge issued by a governing body the way ISO certification works. A vendor describing themselves as "SOC 2 certified" is using imprecise language at best — which is itself a small, useful signal about how carefully that vendor handles precision generally.
Type I versus Type II — the distinction that matters most
A Type I report evaluates whether controls are suitably designed at a single point in time. It answers "do these controls exist and make sense on paper," but says nothing about whether they were actually followed in practice.
A Type II report evaluates whether those controls operated effectively over a period, typically six to twelve months. This is a materially stronger claim — it means an auditor observed the controls functioning over time, not just their design.
If a vendor offers you a Type I report and describes it as equivalent to Type II, or does not proactively distinguish between the two, that is worth asking about directly.
What the Trust Services Criteria actually cover — and the scope trap
A SOC 2 report is scoped to specific criteria the vendor chose to be evaluated against. Security is typically mandatory; availability, processing integrity, confidentiality and privacy are often optional additions. A vendor can hold a genuine, unqualified SOC 2 report that covers security but says nothing about privacy — and a report covering "security" alone is not the same claim as a report covering all five criteria.
Read the report's actual scope section, not just its existence. The specific controls tested and the specific criteria covered matter more than the fact that a report exists at all.
What a SOC 2 report does not tell you
It does not evaluate the product's functional security, like code-level vulnerabilities. SOC 2 evaluates organisational controls — access management, change management, monitoring — not whether the codebase itself has been penetration tested or contains known vulnerabilities.
It does not cover sub-processors automatically. If the vendor uses other vendors — a cloud provider, an AI model provider, an analytics tool — the SOC 2 report may or may not extend to how those sub-processors handle your data. Ask specifically.
It does not mean the vendor is free of "exceptions." A SOC 2 report can and often does note exceptions — instances where a control did not operate as designed during the period. A report with disclosed, remediated exceptions is arguably more trustworthy than one claiming a spotless record, because auditors reliably find something worth noting in any organisation of meaningful size. Ask to see the exceptions section, not just the cover letter.
It is a point-in-time or period-specific document. A Type II report covering last year says nothing definitive about controls today. Ask for the current report, and ask how frequently the vendor renews it.
Questions worth asking when a vendor cites SOC 2
Type I or Type II, and covering what period?
Which Trust Services Criteria are actually in scope?
Can we see the exceptions noted in the report, not just a summary?
Does the report's scope extend to your key sub-processors, or do we need to evaluate those separately?
Can we see the actual report, under NDA if necessary, rather than a marketing page that mentions it?
A vendor's willingness to share the actual report, rather than a badge or a claim, is itself informative.
What we do
We treat a vendor's SOC 2 report as a starting point for questions, not an answer that ends the conversation. If you are evaluating a vendor's security posture and want the actual report read properly rather than taken at face value, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.