SOC 2 Pentest Requirements: What Your Auditor Actually Expects

If you are preparing for a SOC 2 audit, you have probably heard that you need a penetration test. You have also probably noticed that the SOC 2 standard itself is frustratingly vague about what that actually means. There is no checklist. No explicit requirement that says "conduct a penetration test annually." And yet, every auditor we have worked with expects one.

This post breaks down what SOC 2 actually says about security testing, what your auditor will look for in a pentest report, and how to avoid the scoping mistakes that trip up most companies the first time around.

SOC 2 Does Not Explicitly Require a Pentest. Your Auditor Will Anyway.

Let us get the uncomfortable truth out of the way: the AICPA Trust Service Criteria do not contain a line item that reads "you must conduct an annual penetration test." The framework is principles-based, not prescriptive. It tells you what outcomes to achieve, not exactly how to achieve them.

But in practice, penetration testing has become a de facto requirement. Auditors treat it as one of the primary ways to demonstrate that you are meeting the security criteria. If you show up to your SOC 2 Type II audit without a recent pentest report, expect a finding, a qualification, or at the very least, an awkward conversation.

The Trust Service Criteria That Matter: CC7.1 and CC7.2

The two criteria most directly tied to penetration testing are CC7.1 and CC7.2 under the Common Criteria (Security) section.

CC7.1: Detection and Monitoring

CC7.1 requires the entity to "detect and monitor for vulnerabilities and threats to system components." This is where vulnerability scanning and penetration testing come in. Your organization needs to show that it actively identifies weaknesses in its environment, not just that it has firewalls and antivirus deployed. A penetration test provides direct evidence that you are identifying real, exploitable vulnerabilities in your systems.

CC7.2: Anomaly Detection and Response

CC7.2 requires the entity to "monitor system components for anomalies that are indicative of malicious acts, natural disasters, and errors." While this criterion leans more toward monitoring and incident detection, a penetration test can validate that your detection mechanisms are actually working. If a tester can exfiltrate data without triggering an alert, that is a finding your auditor cares about.

Beyond CC7, penetration testing also supports criteria related to risk assessment (CC3.2), change management (CC8.1), and logical access controls (CC6.1). A thorough pentest touches many areas of the Trust Service Criteria simultaneously, which is part of why auditors value it so highly.

What Auditors Actually Look for in a Pentest Report

Not all pentest reports are created equal, and auditors know the difference. Here is what they are evaluating when they review your report:

1. Scope That Matches Your SOC 2 Boundary

This is the single most common issue we see. Your pentest scope needs to align with the systems, applications, and infrastructure defined in your SOC 2 boundary. If your SOC 2 covers your SaaS platform, your API layer, and your AWS infrastructure, then your pentest needs to cover all three. Testing only the web application front end is not sufficient if your SOC 2 scope includes back-end services and cloud infrastructure.

2. Testing of Both Internal and External Surfaces

Auditors want to see that you are not just testing what is visible from the internet. External testing shows how an outsider could get in. Internal testing (or authenticated testing) shows what happens once someone has access. Both perspectives matter. If you only have an external, unauthenticated test, you are leaving a significant gap in your evidence.

3. Risk Ratings Using CVSS or a Similar Framework

Findings need to be rated by severity in a consistent, industry-recognized way. CVSS (Common Vulnerability Scoring System) is the most widely accepted standard. Your auditor wants to see Critical, High, Medium, Low, and Informational classifications with clear scoring methodology. A report that just lists findings without risk ratings will not satisfy most audit firms.

4. Evidence of Remediation or a Remediation Plan

A pentest that finds vulnerabilities is only half the story. Your auditor wants to see that you have either remediated the findings or have a documented, time-bound remediation plan. Ideally, you have a retest report showing that critical and high-severity findings have been fixed. If remediation is still in progress, a plan with owners and deadlines is the minimum expectation.

5. Report from a Qualified Third Party

Internal security assessments are valuable, but for SOC 2, auditors expect an independent, third-party penetration test. The testing firm should have qualified, certified testers (OSCP, GPEN, or equivalent credentials). Self-assessments do not carry the same weight and will likely be challenged during the audit.

Common Scoping Mistakes

Scoping is where most SOC 2 pentests go wrong. These are the mistakes we see most often, and any of them can result in audit findings or the auditor rejecting the pentest report entirely.

• Testing only the web app but not the API. If your product has a front-end application and a back-end API (and it almost certainly does), both are in scope. APIs often have weaker access controls and are where the most critical vulnerabilities live. Testing the web interface alone does not validate the security of your API endpoints.
• Forgetting cloud infrastructure. If your SOC 2 scope includes AWS, Azure, or GCP resources, your pentest needs to cover them. Misconfigured S3 buckets, overly permissive IAM policies, and exposed cloud services are common findings that auditors care about. A web app test does not cover infrastructure.
• Not including authenticated testing. An unauthenticated test shows what an anonymous attacker can do. But most real-world breaches involve some level of authenticated access, whether through stolen credentials, social engineering, or insider threats. Skipping authenticated testing leaves a major blind spot.
• Scoping too narrow vs. the SOC 2 boundary. Your pentest scope should match or exceed your SOC 2 boundary. If your SOC 2 report covers five applications and your pentest only tested two, your auditor will flag the gap. Work with your auditor and your pentest provider to align scope before testing begins.

Unauthenticated vs. Authenticated Testing

This is one of the most frequent questions we get from companies preparing for SOC 2: do we need unauthenticated testing, authenticated testing, or both?

For SOC 2, you almost certainly need both. Unauthenticated testing covers your external perimeter. Authenticated testing covers the controls that matter once someone is inside your application. Most SOC 2 auditors expect to see both perspectives in your report. If budget forces you to choose, authenticated testing generally provides more valuable findings for compliance purposes, but an unauthenticated baseline is still strongly recommended.

How Often Do You Need to Test?

The short answer: at least annually. SOC 2 Type II audits cover a period of time (typically 12 months), and your auditor will want to see a pentest that falls within that period. An annual test is the minimum expectation.

That said, auditors look favorably on organizations that test more frequently. Here is the general cadence we recommend:

• Annual penetration testing:the minimum for SOC 2 compliance. Your pentest report should fall within the audit period.
• After major changes:if you launch a new product, migrate infrastructure, or make significant architectural changes, a targeted pentest is warranted.
• Quarterly vulnerability scanning:while not a full pentest, regular vulnerability scans between annual tests show continuous monitoring and are viewed positively by auditors.
• Continuous testing: Ongoing security validation through a client portal provides real-time findings and remediation tracking. This is the gold standard and demonstrates to auditors that security testing is a continuous process, not just an annual checkbox.

What a Good SOC 2 Pentest Report Looks Like

Your pentest report is going directly to your auditor. It needs to be professional, thorough, and structured in a way that maps to what auditors are evaluating. Here is what a good SOC 2 pentest report includes:

• Executive summary with overall risk posture and key findings in business language.
• Scope definition that clearly states what was tested and maps to the SOC 2 boundary.
• Methodology section describing the testing approach, tools used, and standards followed (OWASP, PTES, NIST).
• Detailed findings with CVSS scores, proof-of-concept evidence, reproduction steps, and business impact analysis.
• Risk ratings categorized as Critical, High, Medium, Low, and Informational.
• Remediation guidance with specific, actionable recommendations for each finding.
• Retest results confirming that critical and high findings have been addressed.
• Tester qualifications including certifications and firm credentials.

If your pentest report is a two-page PDF with a vulnerability scanner output attached, that is not going to pass muster. Auditors expect a professional-grade deliverable that they can reference directly in their audit workpapers.

Lorikeet SOC 2 Pentest Pricing

We built our SOC 2 penetration testing service specifically for companies going through the audit process. Our reports are structured for auditor review, our scope is mapped to your SOC 2 boundary, and we include retesting to verify remediation.

Both tiers include CVSS-rated findings, executive summaries, detailed remediation guidance, and a report format designed to satisfy SOC 2 auditors. We work directly with your team to align scope to your SOC 2 boundary before testing begins.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.