A buyer asks a vendor for their SOC 2 report, the vendor sends it, the box gets checked, and the deal moves forward. This happens constantly, and it is a good thing, because SOC 2 is a real and useful thing. But I want to be honest about what just happened in that exchange, because the buyer almost always believes something that is not quite true. They believe the report proves the vendor is secure. It does not. A SOC 2 report proves that a company does what it says it does. It says nothing about whether what they say they do is enough, and the gap between those two statements is where real enterprise security lives or dies.
I think about security constantly as the person who builds it into my own product, and I have sat on both sides of this as someone who evaluates other vendors too. The most important thing I have learned is that compliance and security are related but not the same, and treating the certificate as the destination is one of the more dangerous habits in how companies buy and sell software. So let me draw the line clearly, because understanding it will make you both a better buyer and a better steward of your own systems.
What SOC 2 actually verifies
Start with what the report genuinely tells you, because dismissing it would be as wrong as overtrusting it. A SOC 2 audit examines a set of controls you have defined against the trust services criteria, things like security, availability, and confidentiality. A Type II report, the one worth caring about, checks that those controls were not just designed but actually operated over a period of time, usually six to twelve months. An independent auditor looks at evidence and forms an opinion on whether your controls were in place and working as described.
That is valuable. It tells you a vendor has written down their controls, that those controls are not obviously absurd, and that they were followed for a sustained period rather than assembled the week before the meeting. A company that cannot produce a clean SOC 2 report is telling you something, and it is usually not good. So I am not arguing the report is worthless. I am arguing about what it cannot tell you, which is most of what you actually want to know.
Here is the part that gets lost. The controls in a SOC 2 report are largely defined by the company being audited. The auditor checks whether you do what you claimed, not whether your claims describe a genuinely secure system. You can pass a SOC 2 audit with controls that are technically present and substantively weak. The certificate confirms consistency between word and deed. It does not grade the ambition of the words.
The gap between the certificate and the practice
Real security is not a state you achieve and then certify. It is a practice you sustain every day, and most of that practice is invisible to an annual audit by design. The audit takes a sample. It looks at evidence for a control on a set of dates. It cannot watch what your team does at two in the morning when an alert fires and someone has to decide, under pressure and with incomplete information, whether this is noise or a real intrusion. That decision, and the thousands like it, is where security actually happens, and no report captures it.
Consider a few things a SOC 2 report will not reveal about a vendor. Whether their engineers treat security as their own responsibility or as the security team's problem. Whether a reported vulnerability gets patched in hours or sits in a backlog for a quarter. Whether the access controls that look clean on paper have a dozen quiet exceptions that everyone has stopped questioning. Whether the people who would have to respond to a breach have ever actually practiced responding to one. These are the differences between a company that is compliant and a company that is safe, and the audit touches almost none of them.
The most useful framing I can offer is this. Compliance asks "can you prove you did what you said?" Security asks "are you actually hard to attack, and resilient when attacked?" Those questions overlap, but they are not the same question, and a vendor can answer the first one cleanly while failing the second one badly.
Example: I once reviewed a vendor with a spotless SOC 2 Type II report. Their access control policy was documented, audited, and clean. When I asked a more specific question, how quickly access was revoked when someone left the company, the answer was that it happened during a monthly review cycle. So a departed employee could retain access for up to thirty days, and this was fully compliant, because their stated control was a monthly review and they performed it reliably. The report was honest. The practice was a thirty-day window of unnecessary risk that the certificate did nothing to flag.
How to read a SOC 2 report like a skeptic
If you are evaluating a vendor, use the report as a starting point and then ask the questions it cannot answer. The report tells you they are organized enough to have controls and follow them. Your job is to find out whether the controls are any good. I would rather hear a vendor describe a specific incident they handled badly and what they changed than hear them recite their certifications, because the first answer tells me how they actually think about enterprise security and the second tells me they passed an audit.
A handful of questions cut through the certificate quickly:
- How fast do you revoke access when someone leaves, and is it automatic or batched into a review? Speed and automation here reveal how seriously least privilege is actually taken.
- Walk me through your last real security incident. What happened, how did you respond, and what changed afterward? Evasion or a too-perfect answer is itself a signal.
- Who is accountable for security in engineering day to day? If the only answer is "the security team," security is a department, not a culture.
The answers to those questions tell you more about whether your data will be safe than the report ever will, because they probe the practice rather than the paperwork.
Why the checkbox culture is dangerous on both sides
The deeper problem is not any single report. It is the culture that treats compliance as a substitute for security rather than a slice of it, and that culture damages both buyers and sellers. For buyers, the danger is a false sense of safety. A procurement process that collects certificates and stops there has not assessed risk. It has assessed paperwork, and then assigned itself the comfort of having done diligence. The breach that eventually happens will come through a gap that no certificate ever covered, and the post-incident review will note, accurately, that all the required compliance boxes were checked. They were checked. They were also never the point.
For sellers, the danger is subtler and arguably worse. When a security program is organized around passing audits, it slowly optimizes for the audit instead of for safety. Effort flows to the controls that get examined and away from the ones that do not, even when the unexamined ones matter more. The team learns to produce evidence efficiently, which is a different skill from being hard to attack. I have watched security functions become very good at compliance and quietly worse at security, because the incentive structure rewarded the former and only catastrophe punishes the absence of the latter. The certificate becomes a ceiling, and a ceiling is a strange thing to aim for when the sky is the actual target.
The way out of this on both sides is to treat the certificate as the floor and ask what sits above it. A serious buyer uses the report to confirm baseline hygiene and then spends their real diligence on the practice. A serious vendor treats the audit as a useful forcing function for documentation and then aims well past it, because they understand that the audit measures consistency, not safety, and that their customers are trusting them with the second thing whether or not they ever ask about it directly.
What we owe customers beyond the certificate
Companies keep their SOC 2 current because buyers reasonably expect it and because the discipline of preparing for the audit is genuinely useful. It forces a team to write down what they do and to actually do it. But the certificate should never become the ceiling of a security ambition, because the moment a team starts working toward the audit instead of toward actual safety, the audit has quietly become the enemy of the thing it was meant to measure.
The real work sits behind the controls and never appears in the report. It is the automated access revocation that happens in minutes, not at month-end. It is the engineer who treats a security review as part of shipping rather than a tax on it. It is the incident response a team has actually rehearsed, the dependencies patched on a clock measured in hours, the access kept narrow even when narrow is inconvenient. None of that is visible in the document a vendor sends buyers, and all of it is what actually keeps their data safe. So when someone hands over a SOC 2 report, take it for what it is: the starting line, not the finish. Real security is the daily practice behind it, and the practice is what you should be buying.