SOC 2 Penetration Testing Requirements Explained: What Auditors Actually Want to See

1. The SOC 2 Criteria That Penetration Testing Directly Addresses

SOC 2 is built around the AICPA Trust Services Criteria. The Security category (Common Criteria, or CC) is mandatory for every SOC 2 report. The following criteria are the ones a penetration test most directly addresses:

Criteria	What It Requires	How Pentest Evidence Satisfies It
CC6.1	Logical access security over protected assets is implemented and evaluated	Pentest attempts to bypass access controls — documented failures or successes demonstrate whether controls are effective
CC6.6	Logical access security measures protect against external threats	External-perspective web app and API testing directly evaluates this — findings show gaps, clean re-test attestation shows remediation
CC7.1	Detection procedures identify changes that introduce new vulnerabilities	Post-change testing validates no new exploitable paths were introduced — particularly relevant after major product releases
CC8.1	Infrastructure changes are evaluated for security impact	Penetration testing after significant changes provides the "evaluation" evidence required by this criterion
CC9.2	Risks from vendors and third parties are managed	Testing of third-party integrations and OAuth flows satisfies the "evaluated" component of vendor risk management

If you have opted into additional Trust Services Categories — Availability, Confidentiality, Processing Integrity, or Privacy — each has additional criteria that penetration testing partially or fully addresses. Scope your test to cover the systems relevant to each category you have opted into.

2. What SOC 2 Auditors Actually Evaluate

SOC 2 auditors are not security experts. They are CPAs trained to evaluate whether controls are designed appropriately and operating effectively. When they review penetration testing evidence, they are looking for specific markers — not reading the full technical report.

Scope documentation. Auditors want to see that the test covered the systems in scope for the SOC 2 report. If your SOC 2 covers your production web application and database, the pentest must explicitly include those systems in its scope section.
Testing dates within the audit period. The test must have occurred during the observation window. A test dated outside the audit period is not evidence for that period's Type II report.
Third-party tester identity. Auditors want to know who conducted the test. They will note whether it was internal or external, and they increasingly prefer external testers with demonstrated independence.
Finding severity and business impact. Auditors look at whether findings were documented with enough context to understand the business risk. A list of CVE numbers without impact descriptions does not satisfy this.
Remediation status. Were findings fixed? When? Auditors need evidence of remediation during the audit period — typically a re-test attestation letter that confirms critical and high findings were remediated.
Management response. For any findings not remediated (accepted as a risk), auditors need evidence of a management decision to accept the risk, with rationale.

What Auditors Do Not Care About

Auditors typically do not read full technical reports cover-to-cover. They sample. They look at the executive summary, the scope statement, the finding count by severity, the dates, and the remediation attestation. A 200-page technical report is not more valuable than a concise 30-page report with a clear executive summary and a clean remediation letter — as long as the detail is there if they request it.

3. Defining Scope: What Must Be Tested

Your SOC 2 scope document defines the systems the report covers. Your penetration test scope must align to that definition. If your SOC 2 covers your SaaS application and the AWS infrastructure it runs on, your penetration test must cover both.

For most SaaS companies, the minimum scope for a SOC 2-relevant penetration test includes:

Production web application. The application your customers log into. Both authenticated (as a customer) and unauthenticated (as an anonymous user) testing is required, because CC6.1 covers authenticated access controls while CC6.6 covers external-facing attack surface.
Customer-facing APIs. Every endpoint your customers or their integrations call. API testing must include authentication testing, authorization boundary testing, and input validation testing.
Administrative interfaces. Admin panels, internal dashboards, and operator tools that have privileged access to customer data. These are high-value targets that satisfy CC6.1's coverage of privileged access.
Cloud infrastructure configuration. IAM policies, S3/GCS/Azure Blob access controls, security groups, and network segmentation. CC6.1 requires access controls to be evaluated, and cloud misconfiguration is the most common source of access control failures.
Authentication and SSO flows. If you use a third-party IdP or support SAML/OIDC, the authentication flow must be tested for bypass vulnerabilities that would allow unauthorized access to customer data.
Data storage and encryption. Review that data at rest and in transit is encrypted, and that encryption is implemented correctly — not just enabled in configuration.

Scope Agreement Must Be in Writing

Before testing begins, confirm the scope in writing — a signed scope agreement or statement of work. Your auditor may ask to see the scope documentation that was agreed to before the test. "We told them verbally what to test" does not satisfy the documentation requirements for CC8.1.

4. Report Format and Evidence Requirements

SOC 2 auditors do not have a mandated report format they require from penetration testing firms. But reports that satisfy auditor questions without follow-up documentation requests tend to include:

Executive summary. One to two pages summarizing what was tested, the overall risk posture, the number of findings by severity, and a statement on the engagement methodology. Auditors read this first.
Scope and methodology section. Explicit documentation of what was in scope, what was out of scope, what testing methodology was used (e.g., OWASP Testing Guide, PTES), and the testing dates. This is what auditors match against your SOC 2 system description.
Findings with Trust Services Criteria mapping. Each finding should reference the relevant CC criterion it implicates. A SQL injection finding in your customer data API, for example, maps to CC6.6 and CC6.1. This mapping eliminates auditor follow-up questions about which controls are relevant.
Severity ratings with business impact. CVSS scores alone are not enough. Each finding needs a plain-English description of what an attacker could achieve if the vulnerability were exploited — because auditors need to understand business risk, not just technical risk.
Remediation guidance. Specific, actionable remediation steps for each finding. This becomes part of the evidence that your engineering team addressed findings systematically.
Remediation attestation letter. A separate letter (issued after re-testing) confirming that all critical and high findings have been remediated. This is often submitted to the auditor as a standalone document during evidence collection.

5. Remediation and Retest Evidence

Auditors evaluating SOC 2 Type II do not just want to see that findings were identified. They want to see that the organization responded to findings appropriately within the audit period. This requires a structured remediation and retesting process.

Track remediation in a formal system. Every finding should have a ticket in your issue tracker with a due date, owner, and resolution status. Auditors may ask for this as evidence that findings were managed systematically, not just fixed ad hoc.
Retest all critical and high findings. After remediation, the original finding must be retested by the penetration tester to confirm it is resolved. Self-attestation by your engineering team is not sufficient evidence.
Document accepted risks formally. If your organization decides to accept a finding as a risk rather than remediate it, document that decision: who approved it, what compensating controls exist, and what the review date is. Undocumented accepted risks are audit findings.
Close the loop before evidence collection ends. The remediation attestation letter must be dated within the audit observation period. If you remediate findings after the period ends, that remediation does not count as evidence for the current Type II report.

6. Frequency and Timing Requirements

SOC 2 does not specify an annual penetration testing requirement the way PCI DSS does. But auditors evaluating a 12-month Type II observation window expect to see evidence of active security testing during that window. In practice, this means:

At minimum one test per audit period. For a 12-month Type II observation window, at least one penetration test during that period. Most mature companies do annual testing.
After significant architecture changes. If you migrated to a new cloud provider, made a major infrastructure change, or launched a significant new feature that handles customer data, auditors expect to see testing evidence for that change.
After a security incident. If you experienced a security incident during the audit period, auditors will expect to see evidence of post-incident testing to verify the root cause was addressed and no other similar vulnerabilities exist.

7. Can You Use an Internal Tester?

SOC 2 does not require an external penetration tester. Technically, an internal security engineer can conduct the test. However, there are several reasons external testing is strongly preferred:

Independence. An internal tester who helped build the system they are testing has inherent blind spots. External testers bring no assumptions about how the system works and attack it the way an adversary would.
Auditor credibility. When an internal team tests their own system and reports no critical findings, auditors may question the completeness and objectivity of the testing. External reports from firms with established methodologies carry more weight.
Enterprise customer requirements. Many enterprise customers who review your SOC 2 report — and the associated security documentation — will specifically ask whether penetration testing was conducted by an independent third party. Internal testing can become a barrier in enterprise sales even when the audit accepts it.
Regulatory precedent. If you ever face regulatory scrutiny (HIPAA, FTC, state data protection), external penetration testing evidence is significantly more defensible than internal testing evidence.

8. How NullStrike Structures SOC 2 Engagements

Built for Auditor Review, Not Just Technical Completeness

NullStrike has worked alongside every major SOC 2 auditing firm. We know what each firm's evidence review process looks like and what makes auditors close findings versus generate follow-up requests. Our SOC 2 engagements are structured from the start around producing evidence that passes auditor review without requiring you to explain or supplement it.

Before testing begins, we collect your SOC 2 scope documentation and Trust Services Criteria selection. We use that to define exactly what systems must be tested and how findings should be mapped. After testing completes, our report includes an explicit SOC 2 evidence section that maps every test conducted to the relevant criterion.

Scope alignment call before engagement. We review your system description and SOC 2 scope document before scoping the test. This ensures no gaps between what the audit covers and what gets tested.
Trust Services Criteria mapping in every report. Every finding section includes a "SOC 2 Criteria Impact" field that lists the relevant CC controls. Your auditor does not need to make this connection — we make it for them.
Structured severity ratings. We use CVSS as a baseline and layer business impact analysis on top. Every finding includes a "Business Impact" section that describes what an attacker could access or do — written for a non-technical auditor to understand.
Remediation tracking template. We provide a remediation tracking template that maps to your issue tracker. This becomes your evidence of systematic finding management during the audit period.
Formal remediation attestation letter. After retesting, we issue a signed attestation letter confirming the status of each finding. This is the document your auditor receives as final evidence.
Auditor response support. If your auditor has questions about the engagement — methodology, scope decisions, or specific findings — we respond directly. You do not need to translate between auditor and penetration testing firm.

9. Common Auditor Questions and How to Answer Them

Based on what we have seen across dozens of SOC 2 audits, here are the questions auditors most frequently ask about penetration testing — and how to answer them with NullStrike evidence:

"What was the scope of the penetration test?"

Answer with the scope section of the NullStrike report, which explicitly lists all tested systems, IPs/domains, and application components — and confirms alignment with your SOC 2 system description.

"Were any critical or high findings identified? How were they remediated?"

Answer with the NullStrike remediation attestation letter, which lists every finding by severity and confirms the remediation status of each. Critical and high findings include the retest date and confirmation of resolution.

"Was the test conducted by an independent third party?"

Yes. NullStrike is an independent security firm with no involvement in the design, development, or operation of the systems we test. Our engagement letter, scope agreement, and report header all confirm this independence.

"How does the penetration testing relate to CC6.6?"

Answer with the Trust Services Criteria mapping table in the NullStrike report, which explicitly ties each test category and finding to the relevant criterion. The CC6.6 section will reference the external-perspective web application and API testing performed, with findings and remediation status.

Get a SOC 2 Penetration Test That Passes Auditor Review

We scope, test, report, and attest in a format your auditor can close without follow-up questions. Share your audit timeline and SOC 2 scope and we will have a proposal back to you within 24 hours.

Book Free Scoping Call View Sample Report

Summary

SOC 2 penetration testing requirements are not spelled out in a checklist — they flow from the Trust Services Criteria, specifically CC6.1, CC6.6, CC7.1, CC8.1, and CC9.2. Meeting these criteria requires more than a vulnerability scan. It requires active, adversarial testing with documented findings, systematic remediation, and third-party attestation of resolution.

The firms that pass SOC 2 audits cleanly year after year do the same things: they test early in the audit period, they remediate findings promptly, and they work with penetration testing partners who understand how to structure evidence for auditor review. That is the NullStrike standard on every SOC 2 engagement.