Who Gives a SOC 2? The Truth About SOC 2 Security Theater

I'm thrilled to announce that Edera has achieved screenshot-grade security.

That's right. We opened our cloud console, took some screenshots, dropped them into a portal, and sent them to someone who has never seen our codebase, maybe never deployed a container, and definitely doesn't know what a hypervisor does. They confirmed that yes, those are indeed screenshots. They appear to show security controls. The date in the corner looks recent enough.

Compliance achieved. Ship it.

I'm kidding. But barely. Because that's basically how a lot of SOC 2 works, and everyone in the room knows it.

The SOC 2 Industrial Complex

SOC 2 has become the enterprise equivalent of a blue checkmark. Everyone wants one. Nobody reads them. And the presence of one tells you almost nothing about whether a company is actually secure.

Here's the dirty secret that nobody in the compliance industry wants to say out loud: a SOC 2 report tells you that security controls existed during a limited audit window. It tells you that an auditor observed them operating. It does not tell you they're good. It does not tell you they'd survive contact with an actual attacker. It tells you that someone, somewhere, checked a box.

Companies routinely spend $100,000 or more on SOC 2 compliance engagements that produce a PDF your customer's security team will skim for five minutes before asking the questions it didn't cover.

I've sat on both sides of this table. I've been the one to produce and review the reports. I've stared at a 200-page SOC 2 report from a vendor and thought: cool, but what does your IAM actually look like?

The SOC 2 Checkbox Problem: When Audits Replace Security

When your goal is "pass the audit," you start optimizing for that. Not for being secure. For passing.

The easiest controls to audit are the ones that are easiest to screenshot. Evidence collection becomes a quarterly scavenger hunt – a tax on engineering velocity that produces almost no security value.

And the auditors? I have deep respect for the profession. But the audit firm evaluating your Kubernetes security posture may not have anyone on staff who's ever run kubectl. They're evaluating your controls, not your security. Those are related, but they are not the same thing.

Nobody ever lost a deal because their SOC 2 report was too thorough. But plenty of companies have passed SOC 2 audits while running unpatched infrastructure, using shared credentials, and storing secrets in environment variables committed to Git.

Screenshot-grade security.

What "Giving a SOC" Actually Looks Like

I’ve built compliance engineering programs from scratch. I know what real programs look like.  

Now I'm at Edera, where we build container and AI runtime security. If our own security posture is theater, we have no business existing.

So here's how we think about it:

Compliance is a byproduct of good security engineering, not the goal

‍We don't build controls because an auditor needs to see them. We build controls because they make us more secure. The audit is a checkpoint, not the destination.

Evidence should reflect reality, not a moment in time

If your evidence collection process is "take a screenshot on Tuesday," your evidence is already stale by Wednesday. We treat compliance artifacts the same way we treat code: version-controlled, automated, and continuously validated.

Engineers own their controls

‍Compliance isn't something that happens to engineering. It's something engineering does. If the people building the systems don't understand and own the controls, those controls are decoration.

Who Should Actually Give a SOC (2)?

Your customers should. But they deserve more than a PDF. They deserve transparency about what your controls actually do, how they're implemented, and what your real security posture looks like, not just that they were observed to exist during a twelve-month window.

Your board should. But they should be asking "are we secure?" not "did we pass?" Those are different questions with potentially very different answers.

‍You should. But only if you're willing to do the hard part, building real security into your engineering culture and using compliance as a lens, not a finish line.

The Punchline

SOC 2 isn't useless. I wouldn't have spent years of my career on it if I thought it was. It's a framework, and like any framework, it's only as good as the people implementing it.

At Edera, we give a SOC. We just refuse to pretend that screenshots are a form of security. 

To view our SOC 2 report, check it out on our Trust Center.

FAQ

Does SOC 2 prove a company is secure?

No. SOC 2 shows that certain controls existed during an audit window. It does not verify the effectiveness of those controls against real attacks.

Why do companies still pursue SOC 2?

SOC 2 is widely required in enterprise procurement. It acts as a baseline signal of operational maturity, even though it doesn't guarantee strong security.

What is the difference between compliance and security?

Compliance demonstrates adherence to a framework. Security measures whether systems can withstand real-world attacks.

Why do engineers criticize SOC 2 audits?

Because evidence collection often focuses on documentation and screenshots rather than evaluating actual infrastructure security or attack resilience.