Does SOC 2 Require a Penetration Test?

Strictly, no. Nothing in the SOC 2 criteria uses the words "penetration test." But ask five SOC 2 auditors whether you need one anyway, and four will say yes without hesitating. The fifth will ask hard questions about why you think you don't. Understanding soc 2 compliance penetration testing requirements means understanding the gap between what the standard requires on paper and what auditors expect to see in the field, and that gap is where a lot of founders get surprised mid audit.

What SOC 2 compliance penetration testing requirements actually say

SOC 2 is built on the AICPA's Trust Services Criteria, and the criteria describe outcomes, not tools. They say you must monitor your environment for vulnerabilities and confirm your controls actually work. They do not say "hire a firm to attempt a break-in every year." A vendor who tells you a pen test is mandatory is overstating the standard, even when the advice underneath is sound.

Auditors have tested hundreds of companies against these same criteria. They know a vulnerability scan alone rarely satisfies a skeptical reviewer on the other end of your report. So while the standard is silent on the specific method, professional judgment usually is not. Most licensed CPA firms will flag a Type II engagement with no pen test evidence at all, especially once you are handling customer data at any real scale.

Why CC4.1 is the criterion doing the real work

Look at CC4.1, part of the Monitoring Activities section of the Common Criteria, for the specific control language. It requires that you "select, develop, and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." That wording is deliberately broad. A soc 2 pen test cc4.1 connection exists because a penetration test is one of the cleanest ways to demonstrate that evaluation is actually happening, not just described in a policy document nobody reads.

CC7.1 pulls in the same direction from a different angle. It calls for the organization to use detection and monitoring procedures to identify anomalies and evaluate vulnerabilities in the system. A pen test report, dated, scoped, with findings and remediation attached, is concrete evidence for both criteria in one document. That efficiency is a big part of why the practice became the default, even without a rule mandating it.

How often you need a SOC 2 penetration test

Annual is the norm. For most Type II engagements, auditors expect a penetration test within the twelve months preceding the report, timed to fall inside your observation window. If your Type II covers January through June and your last pen test was the previous March, that gap draws a question.

The honest answer on soc 2 penetration testing frequency has more texture than a single number.

• Annual, at minimum, for any company past its first Type II cycle.
• After a significant change to your architecture. A new production environment, a major cloud migration, or a customer facing feature that touches sensitive data all count. Auditors read "significant change" broadly.
• Tied to your observation period, not the calendar. A three month Type II still wants a pen test that is current, not one that predates the window entirely.
• More often if you sell into regulated industries. Fintech and healthcare buyers sometimes ask for evidence twice a year, regardless of what your auditor technically requires.

Vulnerability scanning runs on a tighter cadence, usually monthly or quarterly. That gap between scan cadence and pen test cadence is the piece companies most often get backwards.

Penetration test vs. vulnerability scan

A vulnerability scan is automated. It runs a tool against your systems, matches what it finds to a database of known weaknesses, and hands you a list ranked by severity. Fast, cheap, and you can run it every week without thinking twice.

A penetration test is a person, or a small team, actually trying to get in. They chain small weaknesses together the way a real attacker would. They test logic flaws a scanner cannot see, like whether one customer's account can pull another customer's data. Then they write up what they were able to do, not just what they found. The NIST Technical Guide to Information Security Testing and Assessment (SP 800-115) lays out that methodology difference, and it is the reference most auditors point to when a company asks why a scan report was not enough.

Most SOC 2 relevant tests are run gray box. The tester starts with a standard user account, the same access level a real customer would have, rather than zero information or full source access. That mirrors the risk that actually worries an auditor. Not a nation state attacker starting from scratch, but a compromised or malicious customer credential poking around where it should not. A pure black box engagement can miss authorization flaws that only surface once you are logged in.

Auditors want the scan and the test both, on different clocks. The scan proves ongoing monitoring. The pen test proves someone tried to break the thing on purpose and documented what happened.

What your auditor actually wants to see in the report

A pen test report alone does not close the evidence request. Your auditor looks for a handful of specific pieces.

• Defined scope covering the systems that process, store, or transmit the data in your SOC 2 boundary, not just a marketing site.
• A qualified tester, internal red team or third party firm, with a methodology described in the report itself and credentials such as OSCP or GPEN on the individuals doing the work.
• Dated findings that fall inside or reasonably close to your observation period.
• Evidence of remediation. You need to show the critical and high findings actually got fixed, not just logged somewhere.
• A retest or verification step for anything serious enough to matter, confirming the fix held.

Skip the remediation evidence and you create a new problem. An auditor who sees a critical finding sitting open for six months will ask exactly what your control environment was doing about it. "We meant to get to it" does not produce a clean opinion.

What to look for in a pen testing vendor

Not every firm that sells "penetration testing" understands SOC 2. Plenty are built around network and infrastructure work for larger enterprises, which is a different skill set than testing a multi-tenant SaaS web application and its API. A few questions separate a firm that will actually help your audit from one that will just hand you a scan with a nicer logo. Ask whether they have written reports auditors have accepted before, and ask to see a redacted sample. A vague, three page summary will not satisfy a CPA firm reviewing your evidence.

A good working relationship here tends to outlast a single audit cycle. The firm that tested you this year already knows your application, which usually makes next year's engagement faster and a little cheaper.

When to schedule it, and what it costs on its own

If you are still working out scope, Type I versus Type II, or which Trust Services Criteria you need, that groundwork belongs on its own page. Our guide to SOC 2 compliance for SaaS startups walks through the full picture. The short version relevant here is to schedule the pen test once your environment is stable, usually a few weeks before your observation period closes, so remediation has time to happen before the auditor's fieldwork starts.

A typical test on a single, well-scoped SaaS application takes about one to two weeks of active testing, plus another week or so for the written report. Build in a buffer beyond that for remediation and the retest, since rushing the fix step is exactly what leaves a critical finding open when your auditor asks about it.

On cost, a standalone external pen test commonly runs a few thousand dollars for a small, well scoped SaaS application. Price climbs fast with the number of applications, APIs, and environments in scope, and a retest, if it is not already included, typically adds a few hundred dollars more. That is a separate line item from your CPA audit fees and readiness work, worth budgeting for on its own rather than assuming it is bundled into a generic "SOC 2 package" quote. Deciding which Trust Services Criteria to include in the first place, since security only is the normal starting scope and each addition changes cost and testing burden, gets its own treatment in choosing your SOC 2 Trust Services Criteria.

What happens if you skip it

Nothing stops you from pursuing a SOC 2 report with only automated scanning as your evidence, and your auditor might still issue an opinion. But two things tend to go wrong downstream.

A sharp reviewer on the buyer's security team, the person actually reading your report before signing a contract, often asks directly whether a pen test was performed and when. A shrug is a worse answer than a fixed price would have been. And the gap tends to surface again next cycle, because CC4.1 does not go away. You would be solving the same evidence problem every year instead of building a repeatable process once.

Neither outcome is fatal. Both cost more time than doing the test would have.

If you want a second opinion on whether your current evidence would hold up against these soc 2 compliance penetration testing requirements, start a conversation with CyberSprint and we will walk through what your auditor is likely to ask for before it becomes a fire drill during fieldwork.

Frequently asked questions

Does SOC 2 require an external penetration test, or can an internal team run it?

The criteria do not specify who performs it. An internal team can run the test if they are genuinely independent from the people who built the system and have real penetration testing skill, not just familiarity with a scanning tool. Many companies still choose an external firm because the report carries more weight with buyers and removes any question about independence.

Can a vulnerability scan replace a penetration test for SOC 2?

Not on its own. Auditors generally expect frequent automated scanning to catch known issues quickly, plus a periodic, deeper penetration test to catch what scanning misses. Presenting a scan as your only evidence for CC4.1 is one of the more common gaps auditors flag.

How often does a SOC 2 pen test need to happen?

Annually is the standard expectation for most Type II reports, timed to land inside or close to your observation period. A significant infrastructure or product change can trigger an earlier retest regardless of the calendar.

Does the pen test need to cover our entire company, or just the in scope systems?

Just the systems inside your SOC 2 boundary, the ones that process, store, or transmit the data covered by your report. A marketing site with no customer data typically falls outside scope, though your auditor makes the final call based on your system description.

What if we find a critical vulnerability right before our audit?

Fix it and document the fix. Auditors are generally more comfortable with a company that found and remediated a real issue than one whose testing was too shallow to find anything. What damages a report is an unaddressed finding sitting open with no evidence anyone acted on it.

A penetration test is not a box the SOC 2 standard makes you check. It is the fastest way to answer the question your auditor and your buyers are both going to ask anyway. How do you actually know your controls hold up under pressure, not just on paper?