A clean attestation and a secure environment are related but separate things. Here is where they overlap, where they do not, and how to tell which one you have.
- SOC 2
- Security posture
- Compliance
The short answer
SOC 2 attests that controls you selected, within a scope you defined, operated across a past period. That is genuinely useful and it is not the same as being secure. The overlap is large, roughly the fundamentals every company should run anyway, and the gap is everything an attacker might try that fell outside your chosen scope.
The uncomfortable version: a company can hold a clean report and be one stolen credential away from a serious incident. Both facts fit in the same sentence without contradiction.
On this page
Two different questions
Compliance asks: can you demonstrate that the controls you committed to were designed properly and operated across a defined period? Security asks: can somebody get in?
Both are worth answering. They are not the same answer, and the first does not produce the second as a byproduct. Scope is chosen by the company being audited, and an attestation says nothing about anything left outside it.
What an attestation can and cannot say
The overlap deserves credit. Multi-factor authentication, encryption at rest and in transit, quarterly access reviews and centralised logging are all SOC 2 expectations and all genuinely reduce risk. A company that implements them properly is meaningfully harder to attack than one that has not.
The divergence starts with what an attestation is structurally capable of saying.
| Attestation says | It does not say |
|---|---|
| Controls operated across the observation window | They are operating today |
| Controls within the defined scope were tested | Anything about systems outside that scope |
| Control design was appropriate to stated objectives | The objectives were ambitious enough |
| Evidence supported the controls sampled | An attacker could not bypass them |
What a green dashboard is telling you
A compliance dashboard turns green when the checks a platform can run come back passing. Worth having. Just read it precisely.
Configured
The setting exists and has the expected value. This is what most automated checks verify.
Operating
The control runs consistently across the period, not only on the day somebody looked.
Effective
The control actually stops the thing it exists to stop. Very few dashboard checks reach this.
Password policy configured is not credential theft prevented. Encryption enabled is not data protected against an attacker who already holds valid credentials. Logging on is not anybody reading the logs.
The honest reframe. A green dashboard tells you your paperwork is in order and your baseline configuration is sane. Both matter. Neither is a claim about what happens when somebody attacks you.
What attackers use, and whether SOC 2 sees it
Breach data gives a reasonable picture of what actually goes wrong. Ransomware featured in 44 percent of breaches analysed in the Verizon 2025 Data Breach Investigations Report, and stolen credentials accounted for 22 percent of initial access.
Now hold that against a typical SOC 2 scope.
| Attack path | What SOC 2 typically requires | What it does not reach |
|---|---|---|
| Stolen credentials | MFA enforced, access reviewed | Whether session hijack or MFA fatigue is detected in real time |
| Ransomware | Backups exist, endpoint protection deployed | Whether restores have been tested, whether the agent is actually blocking |
| Web application exploit | Vulnerability management process documented | Whether anything blocks the request in production |
| Exposed API | Inventory maintained | Endpoints shipped since the inventory was written |
The right-hand column is not a criticism of SOC 2. It is a description of what an attestation framework is for. The mistake is reading a report as coverage of that column.
Three questions that separate real from documented
- Would this control stop an attacker, or only record them afterwards?Detective controls matter, and they are not preventive ones
- Is anybody reading what this control produces?An unmonitored alert stream passes audit and stops nothing
- When did somebody last test this from the outside?Configuration review and adversarial testing find different things
Run those against your own control list and the split usually becomes obvious within an hour. Some controls are load-bearing. Others exist because a framework asked.
Why Osto leads with security
Osto’s position is that the certificate is a byproduct of the security, not the other way around. Controls get deployed first: web and API protection, cloud posture management, endpoint and device control, code security, penetration testing. The compliance mapping is then built on top of controls that are genuinely running.
The practical effect is that the dashboard and the defence are the same system. When a control shows as operating, that is because it is doing work in production, not because an API returned an expected value.
SOC 2 remains worth pursuing. It opens enterprise deals and imposes useful discipline. The argument is only about sequence.
Find out what your controls actually stop
A free assessment tests what is running in your environment rather than what is documented, and shows you the difference.
Frequently asked questions
Does SOC 2 compliance mean a company is secure?
No. SOC 2 attests that a defined set of controls were designed appropriately and operated over a period, within a scope the company itself chose. It says nothing about controls outside that scope, and it is a statement about a past window rather than your position today. A company can hold a clean report and still be exposed.
What is the difference between compliance and security?
Compliance asks whether you can demonstrate that agreed controls operated. Security asks whether an attacker can get in. They overlap substantially, because most SOC 2 controls are sensible security practices, but they answer different questions and neither guarantees the other.
Can a company with SOC 2 still be breached?
Yes, and this happens regularly. Attestation covers control design and operation across a defined scope and period. Attackers do not restrict themselves to the scope you defined. Credential theft and ransomware account for a large share of breaches, and both can succeed against organisations with current attestations.
Does a green compliance dashboard mean my controls are working?
It means the checks the platform can see are passing. A dashboard reflects what an API returned, not whether a control stops an attack. Password policy configured is not the same as credential theft prevented, and encryption enabled is not the same as data protected against an authenticated attacker.
Should we skip SOC 2 then?
No. SOC 2 unlocks enterprise deals, gives structure to a security programme, and forces documentation most teams would otherwise defer. The argument is not against the certification. It is against treating the certification as the finish line rather than a checkpoint.
How do I tell whether our security is real or just documented?
Ask three questions. Would an attacker be stopped, or only recorded? Is anyone reading the alerts these controls generate? When did somebody last test this from the outside? Controls that pass an audit but fail those questions are documentation rather than defence.
Related reading: SOC 2 controls CC1 to CC9 · SOC 2 gap analysis · SOC 2 for startups
Accuracy note: Breach statistics are from the Verizon 2025 Data Breach Investigations Report. Control expectations reflect the SOC 2 Trust Services Criteria and vary by scope, auditor and implementation. Current to August 2026.