We passed SOC 2 and still got breached: how that happens

A clean report and a breach are not a contradiction

You spent months on SOC 2. You answered the auditor's questions, gathered the evidence, fixed the gaps they found, and earned the report. You told your customers, and you should have, because it was real work. Then one day an account gets popped, or a vendor you trusted because of their report gets hit, and the question lands hard: what was all of that for?

It is a fair question, and the answer is less alarming than it feels. Passing SOC 2 and getting breached are not a contradiction. They answer two different questions. The report tells you whether the company followed the controls it chose over a past period. Your live security tells you whether an attacker can get in today. Those are not the same thing, and a clean report on the first question says very little about the second.

This is not a knock on SOC 2. We run compliance programs for a living, and a clean report does real work in sales and procurement. The trouble starts only when people read it as a guarantee of safety it was never built to make. So let's look at what the report actually proves, where the gaps are, and what closes them.

What a SOC 2 report actually proves

A SOC 2 report attests to one thing: over a past period, the company followed the controls it said it would, and an auditor tested that it did. That is really useful, and it is narrower than most people hear.

The cleanest way to picture it is a restaurant health inspection. The inspector confirms the kitchen follows its own process, that the fridge is cold and the logs are filled in. The inspector never tastes the food. A SOC 2 audit works the same way. It checks the process. It does not check whether the result is safe to eat.

There are two flavors of the report, and the difference matters. A Type I report is an opinion on the design of your controls at a single point in time, an "as of" a specific date. A Type II report goes further: it is an opinion on whether those controls actually operated effectively over a period, typically six to twelve months. Type II is the one customers usually ask for, because it covers a stretch of real operation rather than a snapshot of intent.

The controls themselves come from the Trust Services Criteria. There are five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the common set that every SOC 2 must include. The other four are optional, and management chooses which ones to bring into the report. So two reports that both say "SOC 2 Type II" can cover very different ground.

Underneath all of it sits the management assertion. Management formally asserts that the system description is fair, that the controls are suitably designed, and (for Type II) that they operated effectively over the period. The auditor then tests the evidence behind those assertions. Keep that order in mind, because it is the root of the gaps that follow: the company describes its own controls, and the auditor checks the company did what it described.

The three gaps between "compliant" and "can't be breached"

Three structural features of a SOC 2 report explain why a certified company can still be breached. None of them is a flaw in the audit. They are simply the edges of what the audit was built to do.

It describes the past, not today

A Type II report covers operating effectiveness over a window that has already closed by the time you read it. The audit looked at, say, last January through December. The report says "we operated these controls over that window." It says nothing about a vulnerability that appeared the week after the window closed, or a setting someone changed last Tuesday, or a person who joined last month.

Attacks are continuous. Attestation is periodic. A report is a snapshot of a moving target, and it was taken a while ago. That gap between the audited past and the live present is permanent, no matter how good the audit was.

You chose what's in scope

The auditor does not decide what gets examined. Management defines the scope of a SOC 2 report, describing the system, and the auditor tests against that description. A service, an environment, or a whole subsystem can sit outside that boundary even if it handles customer data.

This is sharpest with subservice organizations, the cloud providers and subprocessors a company relies on. Most SOC 2 reports use what is called the carve-out method, which excludes a subservice organization's controls from the auditor's testing entirely. The report covers the company's own controls around that provider, not the provider's controls themselves. So the compliance perimeter and the actual attack surface are often two different shapes, and a breach can walk in through the part that was never in the picture.

It checks you did what you said, not that it's enough

This is the subtle one. The auditor tests whether the controls management described are in place and operating. It does not test whether those controls actually stop an attacker.

If management asserts "we run a vulnerability management program," the auditor looks for evidence of that program: scans, tickets, a patch cadence, owners. That assertion can pass cleanly even if the program never caught a particular zero-day, because the auditor is not running an attack against your production system. It is checking that you do what you said you do. Whether what you said is enough to keep an attacker out is a different question, and SOC 2 does not ask it.

How real breaches walked through those gaps

These were not careless companies. They had certifications, security teams, and audits. The breach came through a door the audit was never built to watch. One note on sourcing first: SOC 2 reports are private documents, so in each case below the certification is what the company publicly listed on its trust center at the time, not a report we read.

Okta (2023). Attackers got into Okta's customer support system and accessed support files that included session tokens, which they used to hijack sessions for a handful of affected customers. A stolen, already-authenticated session walks past the password and the multi-factor prompt, because the login already happened. Okta publicly lists SOC 2 on its trust center. This is the "today, not the audited past" gap: a live session-theft technique, not a control that failed inspection. We walked through exactly this mechanic, how a stolen session bypasses MFA, in the first hour of a business email compromise.

Progress MOVEit (2023). A critical SQL injection zero-day, CVE-2023-34362, in Progress MOVEit Transfer was exploited by the Cl0p group starting in May 2023. The fallout reached more than 2,700 organizations, per tracking compiled after the fact. Progress publicly lists SOC 2 on its trust center. This is the "what you said isn't enough" gap, arriving from outside the audited window: a brand-new vulnerability no vulnerability-management control could have caught before it existed.

LastPass (2022). Attackers keylogged a senior engineer's personal device through an unpatched flaw, captured the master password after the multi-factor step, and reached encrypted customer vault backups. LastPass earned SOC 2 Type II attestation in 2017 and maintained it through the breach. This is the human-and-endpoint door: a personal device outside the tidy corporate boundary the audit described. It is the same theme we cover in why "we have antivirus" isn't endpoint management, where the gap is the device nobody is actually managing.

The pattern under these cases is not bad luck, it is direction. According to the Verizon DBIR, vulnerability exploitation has become a leading way attackers get their first foothold, around 31% of breaches, and the human element, someone phished, tricked, or with stolen credentials, remains a factor in most breaches. And these things take a long time to find: IBM's Cost of a Data Breach report puts the average breach lifecycle around 241 days. An annual audit and a breach that takes most of a year to surface are simply operating on different clocks.

How to read a SOC 2 report before you trust it

When a vendor hands you their SOC 2 report, the report is most useful if you read past the cover page. A few minutes spent on the right pages tells you what the certification actually covers for you.

None of this makes the report worthless. It makes the report readable, so you can tell what it actually promises you rather than what you hoped it did.

What actually closes the gap

Compliance is the floor, not the ceiling. SOC 2 gives you a baseline of controls and the discipline to keep evidence of them, which is worth having. It just stops at the edges we walked through: the past window, the chosen scope, the controls tested for existence rather than for whether they stop an attack.

Two things close that gap, and both are ongoing rather than annual. The first is running the program as continuous work instead of cramming for an audit once a year. A real program keeps controls owned, evidence current, and gaps tracked between audits, which is most of the year. That is the work, and it is what our GRC service runs for the companies we manage, so the report reflects how you actually operate rather than how you operated for one window.

The second is someone watching the live environment with the standing authority to act when an attacker is inside. An audit cannot do that, and neither can an alert nobody is positioned to answer. Detection and response is what catches the session theft, the new vulnerability, the compromised device, the things that arrive after the audit window closed and outside the scope it described. That is our MDR work: not a notification when something looks wrong, but the access and the go-ahead to contain it.

Use what you already have. Your SOC 2 program is a real asset, and the controls you have turned on are doing real work. The next step is keeping that program live year-round and putting eyes and hands behind it, which is where we come in.