SOC 2 Penetration Testing: Is It Required? What Reviewers Expect

Penetration testing isn’t explicitly required for SOC 2. The AICPA's Trust Services Criteria don't mandate a pentest. They cite penetration testing as one example of how to evaluate your controls (CC4.1).

But passing your audit and passing a security review aren't the same thing. Your auditor decides the first. Your customers' security teams decide the second, and they expect a real pentest.

In other words, your auditor checks that your controls exist. Your buyer checks whether they're any good.

Pentesting is our company's bread and butter. Our CEO and co-founder, Bryan Onel, spent almost a decade as a pentester.

Why SOC 2 Reports Without a Pentest Get Rejected in Security Reviews

Most rejections stem from a common misconception that a SOC 2 report is a "certification," a binary checkmark that will magically usher you through security reviews. In reality, a SOC 2 report is an auditor's opinion on whether your security controls are designed to meet SOC 2's requirements and, for a Type 2 report, whether they actually operated that way over time.

The problem is that SOC 2's requirements (the Trust Services Criteria) are intentionally broad. They tell you what your controls need to accomplish, not how well they need to accomplish it. A weak program can pass the audit, but passing the audit isn’t the goal. Closing the deal is, and a buyer’s security team won’t accept a weak program.

Most auditors will strongly recommend a pentest during the assessment, even if you haven't listed one as a control. But a recommendation isn't a requirement, and plenty of companies end up with a SOC 2 report that doesn't include one.

That gap is exactly what a CISO, CTO, or IT manager looks for when your report lands in their security review.

Your SOC 2 report shows them your controls exist and work as described. What it doesn't show is whether your product holds up when someone actively attacks it, and it's their data at risk if it doesn't. A pentest is how you supply that evidence.

Vulnerability Scan vs. Automated Pentest vs. Human-Led Pentest

It's easy and cheap to go on Upwork and find a pentester with no real credentials or actual experience, hire them, and have them slap together a "penetration test." There's also a number of services that will run a bunch of automated tools and compile results into a report with "penetration test" at the top.

But neither of these options is going to actually help you build real security, and neither of them is going to help you pass a security review. We see these types of reports get kicked back and rejected often.

What makes a pentest valuable is what it finds and what it leaves out: the authorization flaw that lets one customer read another customer's data, without fifty informational findings burying it. Right now, most AI pentests can't do that reliably. That's the bar we hold our pentests to, whoever or whatever runs them.

Running a scanner and calling it a penetration test is security theater, and CISOs won't accept it. Automated tools have a real place. They're fast, and they catch known issues. They just don't replace a test built to find the flaws that actually matter.

What Matters When Getting a Pentest for SOC 2

Here are the main things we normally recommend clients consider when getting a pentest for SOC 2:

• Security: A pentest that will actually improve your security posture.

• Reporting: An easily understandable, professional, well-written report.

• Credentials: A test performed by a highly credentialed pentester.

• Retesting: The pentester will retest any vulnerabilities they found, and that you fixed.

What a SOC 2 Pentest Report Should Include

When a CISO opens your pentest report, these are the things they check:

1. Scope that matches your SOC 2 system description. If your report covers your web app but the pentest only touched your marketing site, reviewers notice.

2. An executive summary a CISO can read in two minutes.

3. Findings ranked by severity, with steps to reproduce and clear remediation guidance.

4. Remediation status and retest results, so the report shows what you fixed, not just what was found.

5. The tester's name and credentials.

Why Your SOC 2 Pentest Should Make You More Secure, Not Just Close a Deal

When companies come to us for a pentest, it’s usually because a client is already asking to see the report. But if you have to go through the process anyway, why not use it as an opportunity to actually improve your security posture?

Venture-backed startups (or any company with any level of success) are often rapidly growing organizations, hacked together with duct tape and optimism. They also generally have millions of dollars in their bank account and are easily identified on Crunchbase, Hacker News, and Product Hunt.

Read: These are really good targets for threat actors.

The rule of scale is that anything bad that can happen will happen. Applying this to your security posture, with enough exposure, any flaws in your system are eventually going to be compromised. (Yes, even if you have a SOC 2 report.)

Even if you need this ASAP to close a deal, make sure you're building a good foundation for your rapidly growing organization by getting a valuable pentest that's going to help you identify any security vulnerabilities in your product.

If this is going to matter for your business, help you get secure, and unlock more revenue, make sure to do it right.

How to Vet a Pentest Provider for SOC 2

We highly recommend using a pentester that has gone through Offensive Security (OffSec) training and certification and holds an OSCP, OSWE, OSEP, or OSCE3 certification. OffSec's is currently one of the highest-quality programs and certifications available.

Credentials are the start. Before you sign, check these too:

• Scope: Get the scope in writing before any work begins. If a vendor can't tell you exactly what's in and out of scope, you can't tell what you're paying for.

• A certified tester: Ask who's doing the work, then verify their certification on OffSec's site. The tester named in the proposal should be the one testing your system.

• Manual hours in the SOW: Look for testing hours in the statement of work. If the SOW doesn't list them, assume you're mostly paying for a scan.

• A sample report: Ask to see one before you commit. It should be written in clear, professional English, with findings detailed enough for your engineers to remediate and strong enough to hold up in any security review that asks for it.

• Retests included: Confirm retests are part of the price. You shouldn't pay twice to prove you fixed something.

• A contract you can enforce: Sign with a legal entity in a jurisdiction where your contract actually holds up if something goes wrong.

How Oneleet Runs Pentests for SOC 2

Oneleet started off performing a "compliance penetration test" for Y Combinator startups going through the SOC 2 process. We ended up becoming the informal Vanta help desk, which is what dragged us into becoming a complete platform for security and compliance.

Because of that, we know exactly what a pentest needs to look like for your SOC 2 report to hold up in a security review, and what gets kicked back.

What we most often do is considered a "gray box" pentest, where we have some access to your system, but not everything, and then an OffSec-certified pentester goes in and attacks what they think is going to be the highest impact, depending on exactly what your product is doing. Every Oneleet pentester is OSCE-certified.

Retests are unlimited. You fix, we verify, and your report shows remediated findings instead of an open list.

Here’s what this looks like in a bit more detail.

Step 1: Scope

We hold a 30-minute scoping call with your assigned, OSCE-certified pentester present. We get a comprehensive review of your product, including a demo of your application. We agree upon Rules of Engagement (timeline, scope, ways to communicate), and we send you a written summary following the call.

Step 2: Prepare

You provide the permissions and environment details discussed during the scoping call, including documentation and any required credentials. Your supervising team is invited to Oneleet’s platform, where vulnerability management runs.

Step 3: Test

Our pentesters identify weaknesses and attempt to exploit them to assess how deeply they can penetrate your system. Any critical vulnerabilities found are brought to your attention immediately via Slack.

Step 4: Report

We upload all discovered vulnerabilities to Oneleet’s platform. Our internal team revises the report, which is available within 2–3 business days from when the engagement concludes. IT covers an executive summary, risk ratings, detailed findings, and recommendations. 

Step 5: Remediate

You remediate, and our pentesters retest the system within a couple of days. You also have the option to accept the risk or reject the finding. Once all findings are addressed, an updated report reflects the new state of each one.

How Long Does a SOC 2 Pentest Take?

How long a SOC 2 pentest takes depends on the size of your company. We often estimate 20–40 hours for early-stage startups to 100+ for larger enterprises or companies with large surface areas that need to test multiple applications.

If you're ready to get a pentest or simply want to learn more, come chat with us. This is always a bit of an art, and after learning more about your system, we can provide a more accurate quote.

SOC 2 Pentest FAQs

Is penetration testing required for SOC 2 Type 1?

Not by the criteria themselves. A Type 1 report evaluates control design at a single point in time, and many companies skip the pentest at this stage. That's a mistake if you'll hand the report to enterprise buyers, because their security teams expect pentest results no matter which report type you have.

Can a vulnerability scan replace a pentest for SOC 2?

No. Scans and pentests do different jobs. A scan flags known vulnerabilities automatically. A pentest is a credentialed person actively trying to break in, including through business-logic and authorization flaws that scanners miss. Reviewers who ask for a pentest will usually reject a scan report that's been relabeled.

How often do you need a pentest for SOC 2?

We recommend having a pentest done annually, as some frameworks require at least an annual pentest. For a Type 2 report, schedule the pentest inside your audit window so the results line up with the period your auditor reviews. Retesting after you remediate shows reviewers you actually fixed what was found.

What is a gray box penetration test?

A gray box pentest gives the tester partial knowledge of your system, such as user credentials or architecture docs, but not full source access. It sits between black box (no knowledge) and white box (full access). For most SaaS startups, it's the most efficient way to find high-impact vulnerabilities within a fixed number of hours.

How do I choose a pentest vendor for SOC 2 compliance?

Ask four things. What are the credentials of the pentester who actually does the testing? How many manual testing hours are in the statement of work? Can you see a sample report? Are retests included? If a vendor can't answer clearly, you're likely buying an automated scan with "penetration test" printed on the cover.