What SOC 2 Type II Actually Tells You About a Software Partner

A vendor sends you a security questionnaire response that says SOC 2 Type II. Your procurement team treats it as a pass. Six months later an auditor or a customer asks what that report actually covered, and nobody on your side can answer.

This happens constantly, and it is not because anyone was careless. SOC 2 is genuinely useful, but it is also widely misunderstood in ways that make it easy to over-read. Two vendors can both hand you a SOC 2 Type II report and be telling you very different things.

What SOC 2 Is

SOC 2 is a reporting framework built on the Trust Services Criteria, developed by the American Institute of Certified Public Accountants. The criteria are defined in TSP Section 100, published in 2017, with revised points of focus issued in 2022. The 2022 revision updated the guidance rather than the criteria themselves, so the underlying framework has been stable since 2017.

There are five criteria: security, availability, processing integrity, confidentiality, and privacy. That list is where most of the confusion starts.

Only One of the Five Is Required

Security is mandatory in every SOC 2 examination. The other four are optional, included or excluded based on what the organization commits to its customers and what its buyers ask for.

So a vendor telling you they have SOC 2 is telling you they were examined against security. It does not tell you their report covers availability, confidentiality, or privacy. If the data you plan to hand them is personal or regulated, and their report does not include confidentiality or privacy, the report is not addressing your actual question. Ask which criteria were in scope, not whether they have a report.

Type I and Type II Answer Different Questions

A Type I report evaluates whether controls are suitably designed at a single point in time. A Type II report evaluates whether those controls operated effectively over a period of time.

The distinction matters more than the labels suggest. Type I says the design was sound on a particular day. Type II says the controls actually worked across an observation window. That window has a start date and an end date, and both belong in your notes. A Type II report covering a three-month window ending 14 months ago is a weaker signal than the phrase Type II implies on its own.

It Is an Attestation, Not a Certification

A CPA firm issues a SOC 2 report as an attestation on the design and operating effectiveness of controls. No body certifies anyone. This is why the phrase SOC 2 certified, which appears on a great many vendor websites including some that should know better, is technically wrong.

This is a small thing and it is worth noticing anyway. A vendor who describes their own attestation precisely is showing you something about how they handle precision generally.

What SOC 2 Does Not Cover

A SOC 2 report is not a substitute for a regulatory obligation that attaches to your data. It is not HIPAA compliance, it is not PCI DSS, and it does not transfer your obligations to your vendor.

The framework does allow mapping. AICPA guidance permits a SOC 2 examination that maps controls to other frameworks, and mappings to HIPAA, NIST, and HITRUST are common in practice. If your data carries a specific regulatory obligation, ask whether such a mapping was performed and to which framework, rather than assuming the base report reaches it.

Two further limits worth holding onto. The organization designs its own controls to meet the criteria, so scope varies meaningfully between reports. And the report describes a system as it was during the observation window, not as it is today.

Five Questions Worth Asking

1. Which of the five Trust Services Criteria were in scope, and why those?
2. What are the exact start and end dates of the observation window?
3. Were there exceptions noted, and what was done about them? Exceptions are normal. A report with none is worth a second look, not a first pass.
4. Which systems and which environments were in scope? A report covering a production platform may say nothing about the environment where your project will actually be built.
5. Was any framework mapping performed, and to what?

A vendor who answers these five easily is one who has been through the examination and understood it. A vendor who answers by re-sending the badge has told you something too.

Why This Matters More for Smaller Engagements

Large enterprises have procurement functions that ask these questions as a matter of routine. A 50 to 500 person company usually does not, which means the security review of a development partner often lands on an engineering leader who is already running delivery.

The practical consequence is that the badge does more work than it should. It becomes the whole review rather than the start of one. Five questions and twenty minutes of your time closes most of that gap.

Clear Function completed a SOC 2 Type II examination and works with mid-market teams handling regulated and sensitive data, from custom software development to database development and management. If you are evaluating a development partner and want a second read on what a report actually covers, get in touch and we will walk through it with you.