The vibe-coder's guide to your first SOC 2 pentest

You built quickly, maybe with a lot of AI-generated code, landed a real customer, and then their security team asked for your SOC 2 report. Somewhere in the back-and-forth, the word "penetration test" appeared, and now you are trying to figure out what you actually need to buy, how much it costs you in time and panic, and whether you are about to fail something. Here is the honest version, minus the jargon and minus the fear-selling.

Does SOC 2 even require a pentest?

Strictly, no, and anyone who tells you otherwise is simplifying. SOC 2 is built on the AICPA's Trust Services Criteria, and the word "required" does not sit next to penetration testing anywhere in them. What the criteria do is name it directly. Criterion CC4.1 expects management to use a variety of ongoing and separate evaluations, and its points of focus explicitly list penetration testing as one of them.

So the technical answer is "not mandated," and the practical answer is "yes, in all but name." In current practice, most auditors treat a pentest as the default evidence for CC4.1, especially on a Type 2 report. If your evidence binder has no pentest in it, the auditor's first question is why not, and you had better have a documented justification and some alternative evidence ready. For almost every startup, producing the pentest is dramatically easier than defending its absence.

What a pentest is, and what it is not

A vulnerability scanner matches your software against a database of known patterns and prints everything that looks suspicious, including a healthy number of things that are not actually exploitable. A penetration test proves impact: a skilled adversary, human or AI-native, actually exploits a weakness and demonstrates what it lets them do. The difference is the difference between a smoke detector going off and someone showing you the fire. Auditors, and your customers, want the second thing: verified findings with evidence, not a wall of scanner maybes that nobody has triaged.

What auditors actually look for

• A real test against a recognized methodology. For web applications, the OWASP Top 10 and the Web Security Testing Guide are the common reference.
• Findings with severity, evidence, and specific remediation, not a raw tool dump with the vendor's logo on the cover.
• Proof you remediated the important ones, usually through a retest that confirms the fix.
• A report dated within the audit period and scoped to the systems actually in question.

Where AI-built code tends to break

If you shipped fast with AI assistance, it is worth knowing where the pressure usually finds cracks, because it is predictable. Independent testing of AI-generated code keeps landing in the same range: Veracode's 2025 GenAI Code Security Report found roughly 45% of generated samples introduced an OWASP Top 10 weakness, and a Stanford study found developers using AI assistants wrote less secure code while feeling more confident about it. The recurring culprits are familiar: missing object-level authorization (IDOR), inconsistent input handling between routes, secrets that slip into the client bundle, and auth flows that were good enough to demo. These are exactly the categories a good pentest goes straight at.

The goal is not to pass a checkbox. It is to find what an attacker would find, before they do, and to be able to prove you fixed it.

What the engagement actually looks like

Practically, the flow is straightforward. You define scope: which application, which environments, which accounts the testers get (lean toward giving them more access, not less, it produces a better test). The test runs against a production-like environment. You get a report with proof-backed findings ranked by severity. You fix the important ones. The testers retest and confirm closure. You hand the final report to your auditor and your prospect's security team, and you move on with a real answer instead of a nervous one.

With Uvy, you point us at your application, we run the full methodology and show you a working exploit for the findings that warrant one rather than a list of maybes, you get an audit-ready report, and we retest to confirm the important findings are closed. That is usually all your auditor needs, and all your customer wanted to know. See how it works.