Penetration Testing Requirements in SOC 2 Type II Audits

SOC 2 doesn't say the words "penetration test" anywhere in its text. The Trust Services Criteria describe outcomes, not tools, so a strict reading leaves room to argue you could pass without ever hiring someone to break into your own systems. Nobody does that, though. Organizations that show up to an audit without a pen test on file tend to walk away with qualified opinions or a list of gaps to close before the report can ship, and that gap between what's written and what's actually expected is where a lot of engineering leaders get caught flat-footed. This piece breaks down exactly which criteria pen testing satisfies, what auditors want to see as proof, and what separates a program that sails through from one that stalls in week three of fieldwork.

The specific Trust Services Criteria that pen testing satisfies

Start with CC4.1, because it's the closest the framework gets to naming the thing directly. CC4.1 covers Monitoring Activities, built on COSO Principle 16, and it requires the entity to run ongoing or separate evaluations to check whether its controls are actually present and working. The points of focus under CC4.1 list out methods management might use, and the language includes "vulnerability scans, security assessment, penetration testing, and third-party assessments." It's a name-drop rather than a mandate. It's a name-drop, but it's the one clause in the entire criteria set where the AICPA points a finger directly at pen testing as an accepted method.

From there, the coverage spreads out. CC7.1 tests whether your controls actually work, and a pen test is the practical way to prove a monitoring control would catch a real attacker instead of sitting there looking good in a diagram. CC7.2 covers vulnerability management: finding, judging, and fixing weaknesses on a reasonable timeline. Pen testing earns its keep here because automated scanners walk right past things like a broken authorization check that only appears once three low-severity findings are chained together.

CC3.2, the risk assessment criterion, benefits too. A policy review tells an auditor what you think your risks are. A simulated attack tells them what your risks actually are, which is a different and more convincing kind of evidence. CC8, change management, gets covered when testing happens after a deployment and confirms the new code didn't open a door nobody meant to open.

Three of the five Trust Services Principles get touched by this one activity. Security is the obvious one, sitting under CC4.1. Availability shows up under A1.2, since a pen test can reveal conditions that would take a system down in ways a routine scan never flags, like a condition that would take a system down in ways a routine scan never flags. Confidentiality lands under C1.1, when a simulated attack demonstrates how someone could get their hands on sensitive data.

The practical move here is simple: map the pen test scope to these criteria directly in the report, or in a cover memo attached to it. Auditors follow that map. Giving the auditor a scope map makes the evidence review move faster because they're not left guessing which finding ties to which control.

What Type II auditors ask for and reject

Type I and Type II are different asks, and confusing them costs time. Type I checks whether a control is designed well at one point in time. Type II checks whether the control actually operated, consistently, across the entire audit period, typically spanning several months to a year. A pen test finished after that observation window closes doesn't count as evidence for the period under review, no matter how good the report looks. This trips up more companies than it should, usually because someone scheduled the annual test for convenience rather than for audit timing.

The evidence package auditors want, in the order they usually ask for it:

• A written policy that states testing frequency, what's in scope, and how remediation gets tracked. This comes first because it shows the testing is a designed process, not something that happened once by accident.
• The full penetration test report, with dates that clearly fall inside the audit period. A two-page executive summary does not substitute for the report itself.
• Proof the scope actually covered production, matched against the system description filed with the audit. Testing a staging environment and calling it done is a mismatch auditors catch quickly.
• Evidence the testers were qualified: individual certifications, the firm's credentials, or some demonstration of independence from the team that built the system.
• A remediation trail, whether that's Jira tickets, a spreadsheet, or a formal remediation plan. A finding marked "resolved" with nothing behind it is treated as unresolved.
• Retest evidence for anything rated critical or high. Closing a ticket isn't the same as confirming the fix actually worked.

What gets rejected is just as clear. Automated vulnerability scan output dressed up as a pen test report is the most common one, and auditors call it out by name now. So does a test scheduled for a date outside the audit window, a report with no exploitation evidence (just scanner findings behind a cover page), and scope that quietly skips admin panels, CI/CD pipelines, or the SSO provider that happens to have production access.

Hold onto full reports for at least two audit cycles. Auditors sometimes sample across multiple report periods when the observation window runs long, and having nothing but last year's file is its own kind of gap.

How scope decisions shape what the audit evidence proves

Scope is where most of the real audit risk actually lives, more than in the testing methodology itself. If a system shows up in the SOC 2 system description but not in the pen test scope, that's a flag an auditor will raise without hesitation.

What generally needs to be in scope: every production application under the audit, external-facing infrastructure like load balancers and APIs and CDNs, the authentication and authorization layer, customer-facing portals, and any third-party integration that touches customer data.

What gets missed, over and over: admin panels and internal tools that happen to have production access, the CI/CD pipeline itself, SSO providers, and payment processors. These fall outside most people's mental model of "the app," so they get left out of scoping conversations even though they're exactly the kind of thing an attacker would go after first.

Whitebox access, meaning source code, cloud configs, and internal documentation handed to the tester ahead of time, produces a more complete map of the attack surface than discovering it incrementally during a fixed two-week window. Gray-box, where the tester has partial knowledge, is the common middle ground for SOC 2 work and often the practical choice. Pure black-box testing looks appealing because it's more "realistic," but it risks missing internal attack paths that auditors expect to see covered, since a black-box tester spends a chunk of the engagement just figuring out what's there.

A vendor that quotes a flat fee without asking detailed questions about the environment first is usually underscoping the work. That's usually a sign of underscoping, and an underscoped test leaves holes in the evidence that appear later, at the worst possible time. Get a scope document in writing, signed by both sides, before testing starts. That document isn't paperwork for its own sake. It becomes part of the audit evidence package itself.

Frequency: annual testing as the floor, not the target

Annual comprehensive testing is the baseline auditors expect for SOC 2 Type II. Treating it as sufficient, though, misreads what "annual" is supposed to mean.

A reasonable cadence looks something like this: external pen testing once a year, plus another round after any major infrastructure change. Web application testing annually, plus after each major release. API testing annually, backed up by continuous scanning integrated into the development workflow. Vulnerability scanning at least quarterly, with weekly or continuous scanning being the better practice among companies that take this seriously. Internal network testing annually, when internal networks or VPNs fall inside the audit scope.

Here's the actual problem with the once-a-year mindset: a SaaS product can look completely different twelve months later. New APIs ship, new integrations get bolted on, the attack surface shifts entirely, and the pen test report sitting in the compliance folder describes a system that no longer exists. Auditors expect evidence that new deployments got tested for vulnerabilities before or shortly after they went live, separate from the once-a-year comprehensive engagement.

Continuous scanning on every pull request is where this is heading for a lot of engineering teams, because it treats security testing as something the engineering org does constantly rather than a paperwork exercise that happens once a year around audit season. It also produces a steady stream of evidence that maps directly onto CC7.1 and CC7.2, which gives auditors something better than a single report to review.

Build the testing calendar before the audit period starts. Retroactively scheduling tests to cover a period that's already ending doesn't work. The evidence has to be generated during the window, not reconstructed after it closes.

Why the gap between a real pen test and a checkbox scan matters at audit time

A vulnerability scan tells you a control exists. A pen test tells you whether that control holds up against someone actually trying to get past it. That distinction is the entire point of CC4.1, and it's the difference auditors are actually probing for when they ask to see the report.

Quality engagements put somewhere between 60 and 80 percent of the total time into manual testing. Automated tooling plays a role, but it's one part of the engagement, not the whole thing. Manual work is what finds business logic flaws: a discount code that stacks when it shouldn't, an API that lets a user request another account's data by changing an ID in the URL, an authorization check that works fine in the UI but gets skipped entirely if you hit the endpoint directly. None of that appears in scanner output, because scanners look for known signatures, not logic errors specific to your product.

Picture a report that lists an outdated TLS version and a missing security header, and nothing else. That satisfies a compliance checkbox. It says nothing about whether payment processing logic holds up under an adversarial user, whether the access control model actually prevents privilege escalation, or whether authentication can be bypassed with a crafted request. An auditor who's reviewed a genuinely thorough report before will spot the difference immediately.

A finding to put in front of an auditor includes evidence of exploitation, a CVSS score, business context explaining why it matters, documentation of the attack chain if multiple issues were combined, and remediation guidance specific to the actual flaw, not a generic line about applying vendor patches. Reports that are scanner output with a company logo slapped on the cover get flagged as gaps now, and the tell is always the same: findings with no exploitation evidence, and remediation language that reads like it was copied straight from the scanner's template.

The uncomfortable part is that a company can pass its audit with a checkbox-quality pen test and still be sitting on real, exploitable vulnerabilities. It's a delay, because the discovery of the actual weakness gets pushed off until an attacker finds it instead of a tester.

What to look for and ask for when selecting a pen testing provider

Five questions separate a serious vendor conversation from a sales pitch:

• What methodology do they follow, and can they produce a sanitized sample report from a comparable engagement?
• Who is actually running the test, by name, and what certifications does that specific person hold?
• How do they test for business logic flaws and authorization bypasses, beyond what a scanner catches on its own?
• What does the final report contain? Exploitation evidence, attack chains, and enough business context for an auditor to follow the reasoning?
• What's the retest process, and how do they document that critical and high findings were actually confirmed fixed, not just marked closed?

On certifications, look for OSCP, OSWE, or GXPN held by the individual who's actually going to run the engagement. CEH by itself doesn't prove hands-on testing ability. The base CEH exam is multiple choice, and while a separate CEH Practical exam exists, it's optional and not included in the standard credential. A vendor who talks about "our certified team" without naming the person assigned to the work is worth a follow-up question, because firm-level certification badges don't transfer to whoever actually shows up to do the testing.

Methodology matters more than marketing language. A vendor should be able to name the frameworks they follow: the OWASP Web Security Testing Guide for web applications, the OWASP API Security Top 10 as a reference for common API risks, and either PTES or NIST SP 800-115 as the overall structure. "We follow industry best practices," "We follow industry best practices," with nothing more specific behind it, usually shows that no repeatable process exists.

Every finding in the report should be backed by a working exploit, not flagged as a maybe. A report full of "potential vulnerabilities" that were never actually confirmed isn't something an auditor, or a customer's security team, should have to take on faith. Ask for a certificate of professional indemnity insurance before signing anything, since pen testing involves deliberately poking at production systems and things occasionally break.

A sample report is non-negotiable. If a vendor can't produce one, that's the answer to the question of whether their deliverables are any good. Run it against the same bar covered above: exploitation evidence, attack chains, business context, remediation guidance that's actually specific.

Contract structure matters too. Look for vendors willing to be measured on outcomes and risk reduction rather than hours logged or page count delivered. A provider that's comfortable being on the hook for retest verification is building toward an audit that actually passes, not just a deliverable that technically arrives on time. And ask whether there's a direct line, a Slack channel or something equivalent, to the testing team during and after the engagement. Real-time access to ask a remediation question shortens the gap between finding a problem and fixing it, and that gap creates timing risk at audit time.

How SOC 2 pen testing evidence intersects with HIPAA and ISO 27001 requirements

ISO 27001:2022 doesn't hedge the way SOC 2 does. Annex A Control 8.8, on managing technical vulnerabilities, and Annex A Control 8.29, on security testing during development and acceptance, both call for a documented vulnerability assessment process, and pen testing is the recognized way to satisfy it. The transition deadline from the 2013 version of the standard to the 2022 version was October 31, 2025, and that date has passed. Any certification still sitting on the 2013 standard has expired. Only ISO/IEC 27001:2022 is current, and its vulnerability management controls apply across the board now.

HIPAA sits in a different spot. Penetration testing sits as one method among others rather than a standalone requirement under the Security Rule as it currently stands. That's likely changing. HHS published a proposed rule (an NPRM) in January 2025 that would make annual penetration testing mandatory for covered entities and business associates handling ePHI, alongside vulnerability scanning at least every six months. A regulatory freeze hit early in 2025, pushing the timeline back, with the final rule now targeted for sometime in 2027. Waiting for the ink to dry before building this out is a bad bet, especially given the numbers involved: healthcare has held the title of most expensive industry for data breaches for fourteen straight years according to IBM's Cost of a Data Breach Report, averaging $7.42 million per breach and 279 days to identify and contain one. The Change Healthcare ransomware attack, which the company disclosed to OCR affected roughly 192.7 million people, is the scale this kind of gap can reach.

For a SaaS company sitting under more than one of these frameworks at once, the good news is the work overlaps. A whitebox pen test scoped to production, backed by exploitation evidence, a documented remediation trail, and retest verification, does double or triple duty. It satisfies SOC 2's CC4.1 and CC7.1, it covers ISO 27001's Annex A 8.8, and it puts the organization ahead of where HIPAA is very likely headed. One well-scoped engagement, done right, ends up worth more than three separate mediocre ones.