About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
You’re in the middle of your SOC 2 audit. Evidence requests keep piling up. Then someone on your team asks the question that stops everyone: “Wait, does passing this mean we’re actually secure?” The honest answer is no. SOC 2 tells your customers you have the right controls in place. It doesn’t tell anyone whether those controls can survive a real attacker poking at your actual code. That gap, between “written down” and “tested”, is exactly where a custom code pentest earns its place.
What SOC 2 Actually Requires
Here’s the part most teams learn the hard way: SOC 2 does not require a penetration test. The AICPA’s Trust Services Criteria (the rules your auditor checks you against) never say “pentest” is required. What they require is proof. You need to show that you can spot risks, watch your systems, and respond when something goes wrong.
That’s on purpose. SOC 2 tells you what to achieve. It doesn’t tell you which tool to use to get there. So, in theory, an auditor could sign off on your report using only policies, access logs, and automated scans. No human would ever have to try breaking into your app.
In real life, though, auditors have caught on. Most now expect a recent pentest report as proof for the Security criteria. Big customers reviewing your SOC 2 report often ask for one by name, too. So a pentest sits in a strange spot. It’s not required on paper. But it’s hard to skip in practice.
Quick answer
SOC 2 does not force you to run a pentest. But auditors treat one as strong proof that your security program actually works, and most big customers ask for one anyway.
Where the Checklist Ends and Real Risk Begins
An auditor’s job is to check whether your written controls exist and are followed. That’s very different from checking whether an attacker can break through those controls.
Think about what a typical SOC 2 evidence request really checks:
- Does an access control policy exist, and is it followed?
- Are code changes reviewed before they go live?
- Is there a written process for fixing vulnerabilities?
- Are logs kept and watched?
Every one of these can get a confident “yes.” Yet your app can still have a broken permission check that lets one customer see another customer’s data. It can still have an API endpoint that skips login checks entirely. It can still have a flaw that lets someone go from “free user” to “admin” with one edited request.
None of that shows up in a policy document. None of it shows up on an access control list. It only shows up when someone who thinks like an attacker actually tries to break your app the way a real hacker would. That’s exactly what a custom code pentest does. A checklist can’t do it.
SOC 2 Audit vs. Custom Code Pentest: The Key Differences
SOC 2 Audit | Custom Code Pentest | |
What it checks | Whether your written controls exist and are followed | Whether an attacker can actually break your app, logic, and systems |
Who does it | A licensed CPA firm | Offensive security experts (ethical hackers) |
Method | Reviewing evidence, interviews, sampling | Hands-on hacking, code review, testing business logic |
What you get | A report your customers and investors can trust | A technical report with proven exploits and fix steps |
Catches issues from automated scans? | Rarely tests this directly | Yes, plus logic flaws scanners miss |
Catches logic flaws (like broken permissions)? | No | Yes, this is its main job |
Required by AICPA? | Yes, by definition | No, but expected as proof |
Required by big customers? | Often, as the baseline ask | More and more, as a follow-up ask |
How often | Every year (Type II) or once (Type I) | At least once a year, and after big changes |
The takeaway isn’t “pick one.” These two things answer different questions. A strong security program needs both. SOC 2 shows you run a careful, documented program. A pentest shows that program actually holds up under real pressure.
What a Custom Code Pentest Catches That Auditors Miss
This is where “custom” matters as much as “code.” A generic, automated scan will flag known bugs, old software, and setup mistakes. That’s useful, but shallow. A custom code pentest is built around your app, your business logic, and your weak spots. That’s why it keeps finding issues that auditors and scanners both walk right past, such as:
- Broken object-level permissions: changing an ID number in a request lets you see another customer’s data
- Weak separation between customers: a serious risk for any company storing many customers’ data in shared systems
- Ways to gain more access than allowed: chaining a few “small” bugs together into a full account or admin takeover
- Login and session flaws: problems in password resets or single sign-on that pass a checklist but fail under real testing
- Unsafe API endpoints, especially “hidden” endpoints that were never meant to be public
- Business logic abuse, discount codes, rate limits, payment flows, or account tiers that can be tricked in ways no scanner looks for
This isn’t just a theory. Verizon’s 2025 Data Breach Investigations Report found a sharp rise in breaches that started with an exploited weakness, now making up a large share of all confirmed attacks. Attackers don’t check whether you have a SOC 2 report before they try to log in as someone else.
When to Bring a Pentest Into Your SOC 2 Timeline
Timing matters more than most teams think. You usually have three options:
- Before the audit window opens. This gives you time to find and fix problems before your auditor, or a customer, ever sees them. Best if your timeline has room to spare.
- During the audit period, matched to your Type II review window. This is the most common choice, since your pentest report then falls inside the same window your auditor is reviewing.
- Right before your report is due, as a last-minute add-on. This is possible, but it leaves no time to fix anything. A serious issue with no fix in place can turn a strong report into a problem.
If you’re already mid-process, option two is usually still doable. But the time left to fix any issues before your audit closes shrinks with every week that passes.
How to Choose the Right Pentest (Not All Pentests Are Equal)
Not every “pentest” used for a SOC 2 report is really a pentest. Auditors and enterprise security teams increasingly reject reports that are just automated scans with a logo slapped on top. When you scope yours, look for:
- Real, hands-on testing, not just automated scanning. A scanner finds known patterns. A human tester finds what’s unique to your app.
- Grey-box or white-box access. Testers who understand how your app is built find deeper issues than testers guessing blind.
- Scope that matches your actual SOC 2 boundary. The systems tested should match the systems in your audit, not some smaller sample.
- A retest included. Proof that flagged issues were actually fixed, not just written down.
- A report both your auditor and your customers can read. Technical enough to be credible. Clear enough to actually be useful.
If a pentest report can’t answer “did you actually try to break this, and what happened?”, it won’t hold up to a skeptical auditor. It won’t hold up to a real attacker, either.
The Bottom Line
A SOC 2 report tells the world you take security seriously enough to write it down, watch it, and have it checked by an outside party. A custom code pentest tells the world, and, more importantly, tells you, whether that program can actually stop a real attacker. Startups that treat these as the same thing usually find out the hard way that they aren’t. Often that happens during a customer’s security review. Sometimes it happens after a breach.
If you’re in the middle of your SOC 2 process right now, the smartest move is to scope a pentest built around your actual app, timed to fit inside your audit window. Skip the generic scan bolted on at the last minute.
Ready to see what a real, custom code pentest looks like for your stack? [Fill out our scoping form] and we’ll match testing to your SOC 2 timeline and audit scope, usually within one business day.
