Methodology, scope depth, report length, OWASP coverage - your auditor doesn't really care about any of it.
We've watched people disappear into rabbit holes researching OWASP vs. PTES methodologies, debating gray box vs. black box approaches, worrying about whether their report needs to be 5 or 50 pages or 150. Almost all of that anxiety targets the wrong things.
Your auditor has three questions. Here they are.
The Three Questions Your Auditor Will Ask
1. Did you do it? (Recently?)
Evidence needed: Engagement letter and final report from a pentest firm (or documentation of internal testing with appropriate independence).
2. Did it cover the right stuff?
Evidence needed: A scope statement in the report that includes systems within your SOC 2 boundary.
3. Did you act on findings?
Evidence needed: Remediation tracking showing critical and high findings were addressed or formally risk-accepted.
That's the whole checklist. Everything else is good security practice, but it's not what your auditor is evaluating.
Now let's unpack each one.
"The Right Stuff": Scope Alignment
The scope question trips people up more than anything else.
Your SOC 2 audit has a defined boundary—the systems, infrastructure, and processes that deliver your service to customers. This is documented in your system description. Your pentest scope needs to align with that boundary.
If your SaaS application is the core of your service delivery, the application needs to be tested. If your AWS infrastructure hosts customer data, it should be in scope. If you have an admin portal that employees use to manage customer accounts, that's probably in scope too.
The alignment doesn't need to be perfect. Auditors aren't checking whether every single IP address in your system description appears in the pentest scope. They're checking whether the testing meaningfully covered the systems that matter.
What works: "External penetration test of the Acme Platform production environment, including the customer-facing web application (app.acme.com), public API endpoints, and associated cloud infrastructure in AWS us-east-1."
What raises questions: A scope statement that only mentions "corporate network" when your SOC 2 boundary is entirely focused on a cloud-hosted SaaS product.
If there's a mismatch, be prepared to explain why. Maybe your corporate network pentest was separate from your application security testing. Maybe certain systems were tested through a different mechanism. Auditors are reasonable—they just want to understand your rationale.
Timing
For SOC 2 Type I audits, timing is simple: you need evidence that a pentest happened at some point, demonstrating you have the capability.
Type II is where people get caught. A Type II audit covers a period of time—typically 6 to 12 months—and evaluates whether controls operated effectively throughout that period. Your pentest needs to fall within the audit window.
The standard expectation is annual testing. If your audit period is January 1 to December 31, you need at least one pentest with a report date in that range. A pentest from the previous December won't count, even if it was only a few weeks before your audit period started.
Plan ahead: Work backward from your expected audit period. Schedule the pentest early enough that you'll have time to remediate findings before the audit, but not so early that it falls outside the window.
A common timeline for a calendar-year Type II audit:
- Q1: Pentest execution
- Q2: Remediation of critical/high findings
- Q3: Retest of critical findings if needed
- Q4: Audit fieldwork
This gives you breathing room. Cramming everything into Q4 creates unnecessary stress and leaves no time for remediation, not to mention consulting firms are usually slammed Q4 making lead times longer for you.
Remediation: Where Audits Actually Go Sideways
Here's where you should pay attention. The pentest happens. The report comes back with findings. Everyone reads the executive summary, nods seriously, and then... the report sits while other priorities take over.
Months later, the auditor asks for remediation evidence, and there's a scramble to figure out what was fixed, what wasn't, and whether anyone documented anything.
Auditors expect to see:
Findings tracked somewhere. This doesn't need to be sophisticated. A Jira project, a spreadsheet, a Linear board—whatever you already use for tracking work. The point is demonstrating that findings entered your normal workflow rather than disappearing into a PDF.
Critical and high findings resolved. "Resolved" means either remediated or formally risk-accepted. Auditors understand that not every finding gets fixed immediately. What they don't accept is ambiguity—findings that are just hanging there, with no clear status or decision. Don't expect to accept critical risks though.
For risk acceptance, document who made the decision, when, and the rationale. "CEO accepted this risk on March 15 because the affected system is scheduled for deprecation in Q2" is fine. No documentation at all is not fine.
Some evidence of the fix. This can be lightweight. A screenshot showing the vulnerability no longer exists. A code commit reference. A configuration change in your infrastructure-as-code repo. Auditors aren't asking for extensive proof—they're asking for something that connects "finding identified" to "finding addressed."
Retest verification for critical findings. If your pentest identified a critical vulnerability—SQL injection, authentication bypass, exposed credentials—auditors may want to see verification that it's actually fixed. This usually means having the pentest firm retest that specific finding and confirm it's no longer exploitable. Not always required, but increasingly common. If your pentest contract includes free retesting, use it for the high-severity stuff.
What Your Auditor Does Not Care About (But Your Customers Do)
This list surprises people, because these items are important — just not to your auditor. Your next enterprise prospect's security team is a different story. They've reviewed reports, and they can tell the difference between a real engagement and a checkbox exercise.
Specific methodology. Your auditor isn't checking whether the test followed OWASP, PTES, or any particular framework. A buyer's security reviewer knows what a structured methodology looks like, and they know what reformatted scanner output looks like.
Report depth and substance. A 15-page report with clear findings passes the audit fine. But a buyer's security team is reading for evidence of manual testing — authentication bypass attempts, privilege escalation, business logic testing. If every finding in your report is something a scanner could have produced, they'll notice.
Testing approach. Black box, gray box, white box — your auditor doesn't have a preference. But a security reviewer will notice if your SaaS product was only tested externally with no credentials. That tells them you wanted to minimize findings, not find real problems.
Tools, OWASP coverage, and finding count. Your auditor isn't evaluating any of these. An enterprise reviewer isn't checking for specific tools or literal OWASP Top 10 completeness either — but they are evaluating whether the report reflects real depth or a shallow pass. A clean report with thorough documentation of what was tested and why the application held up is strong sales collateral. A clean report with thin methodology reads like the tester didn't try.
None of this changes what you need for the audit. But if that report is landing on a buyer's security desk — and increasingly, it will — the gap between "passed the audit" and "passed the security review" is where deals are won or lost.
A note on what enterprise buyers care about
Your auditor and your enterprise prospect are asking different questions. The auditor wants to see that testing happened and findings were addressed. The enterprise buyer's security team—the people running the vendor evaluation—are reading your pentest report for substance. They've seen dozens or hundreds of these. They know the difference between a thorough test and a checkbox exercise.
If your goal is just passing the audit, the bar is lower than you think. If your goal is surviving security review with a sophisticated buyer, or edging out a competitor, the pentest report becomes sales collateral. It needs to hold up to people who do this for a living.
Choosing a Pentest Firm: What Matters
Given everything above, here's what to prioritize when selecting a provider:
What do you actually need at this point? As discussed above – if you're looking for simply the cheapest way obtain a piece of evidence to pass an audit, use your compliance automations complementary services or a low cost automated firm. If you're looking to use the report as sales collateral for security assurances, look at boutique or name-brand firms.
Clear scope alignment. Can they scope the engagement to match your SOC 2 boundary? Do they understand what systems matter for your audit? Are they testing your office network while ignoring your product? Can they review other high return on investment items like infrastructure configurations?
Timing flexibility. Can they schedule the engagement to fall within your audit window, with enough buffer for remediation? If there's a deal waiting, can they move fast?
Report clarity. Will the deliverable include a clear scope statement, findings organized by severity, and remediation guidance your team can actually act on? Ask to see a sample report. If it reads like it was written for auditors rather than engineers, that's a sign. Can you get report in different formats for different audiences?
Retest options. Do they offer retesting for critical findings—ideally included rather than à la carte? What's the turnaround time?
Remediation support. Will they answer questions about findings after the engagement? Can they verify fixes without a full re-engagement? Better yet: will they help you prioritize what to fix first based on what actually matters, not just CVSS scores?
Experience on both sides. The best pentest partners understand what your enterprise buyers are looking for—because they've been on that side, running vendor security evaluations. They know what a thorough report looks like because they've been the ones deciding whether vendors pass.
When There's a Deal on the Line
The timeline above assumes you're planning ahead. Reality is often different: an enterprise prospect sends a security questionnaire, requests a recent pentest report, and suddenly you're working backward from a deal timeline rather than an audit timeline.
If that's your situation, a few things change:
Speed matters more than perfection. You need a firm that can mobilize quickly and prioritize your engagement. Ask about availability before you ask about methodology.
The report is doing double duty. It needs to satisfy your auditor and hold up to the buyer's security team. Those aren't always the same bar.
You may need more than a pentest. The questionnaire might surface architecture questions nobody on your team can answer confidently. The buyer might want a call with someone technical. The pentest is evidence, but it's not the whole story.
This is where having a security partner—not just a pentest vendor—makes a difference. Someone who already knows your architecture, can answer questionnaire questions without a two-week ramp, and can get on a call with the buyer's security team if needed.
The Bottom Line
SOC 2 penetration testing requirements are less prescriptive than most people assume. Auditors aren't evaluating your security program's sophistication—they're checking whether you have a testing practice and whether you act on what it finds.
Get the scope right. Time it correctly. Track and remediate findings.
Everything else—methodology choices, testing depth, coverage breadth—those decisions should be driven by your actual security goals and what your enterprise buyers expect to see, not by what you think an auditor wants.
