Your SOC 2 is not your security

Every fintech founder eventually has the same conversation with their first enterprise customer. The customer asks for the SOC 2. The founder commissions one. Six months and forty thousand dollars later, the audit closes clean and the deal closes with it.

Then a year passes, the product grows, and one quiet Tuesday the security team finds something that should not be there. The audit was clean. The system was not.

This is not an indictment of SOC 2. It is an honest description of what SOC 2 is and is not, and where the gap between them lives.

What SOC 2 actually attests to

A SOC 2 Type II audit confirms that you have controls in place and that those controls operated as designed over a window — typically three, six, or twelve months. It is a process audit. The auditor verifies that you do what your policies say you do.

The policies are written by you. The scope is defined by you. The auditor checks that you followed your own rules.

This is genuinely valuable. It means a buyer can ask "do you log access?" and trust the answer. It means a regulator can see that you take controls seriously. It means a court, if it comes to that, can see you exercised reasonable care.

What it does not mean is that the controls you wrote are sufficient, that the threat model you imagined matches the one you actually face, or that the implementation of those controls is bug-free.

The two-system problem

Fintech systems usually have two security postures running in parallel.

The first is the declared posture — what your policies say, what your runbooks describe, what the auditor sees. This is what SOC 2 attests to.

The second is the lived posture — what actually happens in production at 3 a.m. when an on-call engineer responds to an incident. What the staging environment looks like after six months of "we will clean it up later." What the third-party SDK that handles your card tokenization is actually doing.

Most breaches do not happen because the declared posture was wrong. They happen because the lived posture diverged from it and nobody noticed.

What to actually do

There are three habits that close the gap.

Treat the audit as a floor, not a ceiling. The auditor checks that you log access. Good. Then ask: are we logging the right things? Are we reviewing the logs? Would a determined insider's actions stand out, or be invisible in the noise? SOC 2 will not ask this. You should.

Run security exercises against the lived system. Tabletop a real incident every quarter. Run a red-team exercise annually. Have someone outside the team try to exfiltrate test data using only public information. The exercises that find the most are usually the ones that target the gap between the runbook and the reality.

Pay close attention to the boring drift. A new SDK gets added without a security review. A staging database gets seeded with a snapshot of production. A vendor's permissions get widened "temporarily" and never narrowed. This drift is what audits do not see and breaches do.

The honest pitch

A clean SOC 2 is necessary. It is also not sufficient. The agencies and consultants who treat it as the finish line — and there are many of them — are selling you the audit, not the security.

When we ship fintech systems, we ship to the lived posture, not the declared one. The audit usually closes clean as a side effect. That is the order the work has to happen in.