DEV Community: Sonu Goswami

SOC 2 Is a Starting Point, Not a Security Guarantee

Sonu Goswami — Fri, 12 Jun 2026 15:25:09 +0000

The amount of confidence organizations place in SOC 2 reports continues to surprise me.

Not because SOC 2 lacks value. It doesn't.

What surprises me is how often the existence of the report becomes the assessment.

During vendor reviews, I regularly hear questions such as:

"Do they have a current SOC 2?"

Far less common is:

"What does the report actually tell us?"

Those are very different questions.

A SOC 2 report is an auditor's assessment of controls within a defined scope and period. It is not a declaration that a company is secure, nor is it a substitute for understanding how a vendor's environment aligns with your own risk profile.

The most informative sections are rarely the ones people focus on. System boundaries, control limitations, complementary user entity controls, exceptions, and scope exclusions often provide more insight than the auditor's opinion itself.

This becomes particularly important when organizations treat SOC 2 as a universal security benchmark. Security is the only mandatory Trust Services Criterion. Availability, Confidentiality, Privacy, and Processing Integrity may or may not be included. Two vendors can both claim to be SOC 2 compliant while undergoing assessments of very different depth and scope.

None of this diminishes the value of SOC 2.

I'm not arguing against SOC 2 reports. I just think too many organizations stop asking questions once they receive one.

That's usually where the review should start, not end.

Product-Market Fit Isn't Enough. You Need Explanation-Market Fit.

Sonu Goswami — Tue, 09 Jun 2026 02:18:31 +0000

One pattern I've noticed in enterprise software:

The product that wins isn't always the product buyers understand best.

It's the product buyers can explain internally.

Those are different things.

A security lead might fully understand your platform.

A compliance manager might love the workflow.

An operations team might see immediate value.

None of that guarantees a purchase.

Because eventually someone has to explain the purchase to people who weren't part of the evaluation.

Procurement.

Finance.

Legal.

An executive sponsor.

The products that move fastest often reduce the amount of explanation required.

Not because they're simpler.

Because their story survives handoffs.

The team evaluating the product is rarely the team approving the budget.

Every internal conversation introduces distortion.

Every handoff creates interpretation risk.

Many deals slow down because the product became harder to explain than the problem it solved.

Founders usually focus on product-market fit.

Far fewer think about explanation-market fit.

Can somebody who wasn't in the demo still understand why this purchase matters?

That's often where deal velocity is decided.

The handoff between evaluator and approver is one of the least visible parts of enterprise sales. Buyers spend weeks learning the product, then have to compress that understanding into a few slides, an email, or a procurement meeting. A surprising amount of deal friction appears in that translation layer.

Many teams assume a stalled deal means the value wasn't compelling. Sometimes the value was clear to the evaluator but never became clear to the people carrying the accountability for the purchase. Those are very different failure modes.

Your AI Security Policies Are Fine. Your Architecture Isn't.

Sonu Goswami — Thu, 04 Jun 2026 10:30:39 +0000

Enterprises have updated their AI security strategy. Most haven't built the architecture to enforce it. Here's where the gap actually lives.

Security teams understand AI changes the risk model. The harder question is whether anything in the current architecture can actually control it.

Most organizations have governance policies. Acceptable-use rules. Model safeguards. Testing processes. All of that is useful and none of it creates coherent enforcement — because AI risk doesn't stay inside the boundaries those controls were designed around.

Here's the problem in practical terms.

AI Doesn't Fail in One Place
The problem is rarely one bad step. It is what happens when several normal steps connect. A user asks something reasonable. The model pulls context from somewhere it has access to. An agent makes a call it was permitted to make. A record changes. None of those events triggers an alert. Together they moved something they should not have.

Traditional point controls inspect a traffic path, filter an input, or monitor a specific tool. They don't see the full execution path. And when AI risk travels through a system the same way legitimate work does, waiting for it to arrive at a checkpoint isn't a security model — it's a hope.

Samsung Did Not Have a Hacker Problem
One Samsung engineer needed help with a bug. Used ChatGPT. Got the answer. Another had meeting notes to clean up — same tool, easier. A third was stuck on a hardware problem and did the same thing everyone does when they are stuck and there is a faster option sitting in the browser tab next to their work. None of them filed a ticket. None of them asked IT. The source code, the meeting content, the hardware data — it all moved before anyone with a security title knew it was moving.

Nobody broke anything. The tool worked as designed. The data left through the front door.

That pattern — AI risk appearing through normal usage, not adversarial action — is exactly what most enterprise security programs weren't built to catch.

Runtime Is Where Behavior Actually Gets Determined
Static reviews evaluate system design. Policies define what should be allowed. Model safeguards reduce known categories of unsafe output.

None of those operate at the moment when a live prompt, retrieved context, available tools, and current permissions combine to produce an actual behavior.

A prompt can lead to a tool call. A tool call can change data. A changed record can trigger another workflow. By the time an alert surfaces, the action has already propagated.

The controls that catch this have to operate at the layer where language is being processed and decisions are being made — not at the perimeter, not in a pre-deployment test, but in the execution path where AI behavior is actually shaped.

The Architectural Gap
The strategy has moved on. The architecture is still catching up.
Governance without runtime enforcement is policy people can acknowledge and route around. Testing without production controls finds weaknesses but doesn't stop misuse. Point controls without a view of the full execution chain miss the risk that travels between steps.

The organizations closing this gap aren't deploying more controls on top of existing ones. They're asking whether their security model operates at the layer where AI behavior is determined — which is runtime, not review.

The risk isn't in the model. It's in what the model can touch, what it can trigger, and what it does before anyone looks.

Building or evaluating AI security architecture for an enterprise environment? The framing has shifted from "what does the model output" to "what can the model reach." That's the right question to be building controls around.