Penetration Testing for SOC 2 Compliance: What Auditors Expect

Untangling the SOC 2 Penetration Testing Requirement

Organizations researching penetration testing for SOC 2 compliance often run into conflicting guidance. SOC 2 does not prescribe one standardized penetration test for every service organization, yet auditors, customers, and procurement teams may still request recent testing evidence. The real question is whether the organization can demonstrate that it identifies exploitable weaknesses, evaluates relevant security controls, and responds appropriately to material findings.

Does SOC 2 Require Penetration Testing?

Security teams preparing for a SOC 2 examination often start with the wrong question: whether penetration testing in SOC 2 compliance is mandatory. It rarely comes down to a single yes or no. SOC 2 does not contain a universal rule requiring every organization to complete a specific penetration test at a fixed interval. Auditors, customers, and enterprise procurement teams may request recent penetration testing evidence, particularly where internet-facing applications, sensitive data, or higher-risk services are in scope, and its absence can therefore prompt questions about how the organization validates technical control effectiveness.

Both things are true at once, since SOC 2 is outcome-focused rather than checklist-focused. The real question an auditor asks is not “did the company run a pentest?” It is whether the organization can show that it identifies exploitable weaknesses, evaluates whether its security controls work, and resolves the findings that matter. Penetration testing can provide strong evidence supporting those objectives when its scope, timing, and remediation process align with the organization’s controls.

SOC 2 examinations are performed against the AICPA Trust Services Criteria and the controls the service organization designs around those criteria. The AICPA defines SOC 2 examinations around controls relevant to security, availability, processing integrity, confidentiality, and privacy, and it does not publish one universal pentest rule for every service organization. SOC 2 is principles-based rather than prescriptive, which is why two organizations can address similar risks through different combinations of testing, scanning, monitoring, and assurance evidence. The absence of an explicit line item requirement does not make technical validation unnecessary, and customers frequently request a pentest report independently of the SOC 2 auditor.

Important distinction: a company may be able to complete a SOC 2 examination without a penetration test, but it still needs sufficient evidence that its applicable security controls are suitably designed and, for Type II, operated effectively. A pentest is not a guarantee of a clean report, only strong supporting evidence for one.

Organizations that want penetration testing for compliance built around recognized frameworks often find that aligning the test with their control language can reduce evidence gaps and clarification requests during fieldwork.

Why Do Auditors Frequently Ask for Pentest Evidence?

A pentest helps an auditor evaluate whether management has credible processes for identifying technical risks, detecting vulnerabilities, testing security controls, evaluating changes to the attack surface, and responding to identified weaknesses. The auditor is not acting as the pentester here. The auditor evaluates the organization’s controls and the evidence supporting them, and a pentest is one strong piece of that evidence.

Auditor questions tend to follow a consistent pattern, and the list below covers what auditors actually expect to see answered.

• How the testing scope was determined, and whether it aligned with the SOC 2 system boundary.
• Whether APIs, cloud resources, and authenticated workflows were included in testing, not just the public perimeter.
• Who performed the test, and whether the tester was independent and qualified.
• What material findings were identified, and how management responded to each one.
• Whether corrected findings were retested, and whether any risks were formally accepted instead.
• Whether the organization followed its own stated testing policy and cadence.
• Whether the testing evidence aligns with the applicable Type II review period.

Auditors care about the complete control process here, not simply the possession of a pentest PDF sitting in a shared drive somewhere.

Which Trust Services Criteria Can Penetration Testing Support?

The precise mapping depends on the organization’s controls and the auditor’s interpretation, so no single mapping is guaranteed to apply. Pentesting may support evidence related to risk identification, monitoring, vulnerability identification, access controls, and corrective action.

The table below shows how a few common control statements might connect to real pentesting evidence.

Organization control	Possible pentesting evidence
The company periodically assesses external application security	External web and API penetration test report
The company identifies and remediates material vulnerabilities	Findings register, remediation tickets, and retest evidence
The company evaluates security after major changes	Testing record following a major release or cloud migration
The company monitors whether security controls operate effectively	Testing results, trend data, and management review
The company validates control effectiveness through independent technical testing	Independent penetration test report with tester qualifications on file

This table illustrates possible evidence relationships, not guaranteed mappings to particular criteria. The AICPA’s current Trust Services Criteria remain the authoritative reference for the five categories and the criteria within them, so do not copy a generic mapping like this one into an audit deliverable without confirming it matches the organization’s own control language.

SOC 2 Type I vs Type II: How Pentesting Evidence Differs

The two report types ask different questions, and that difference changes what pentesting evidence needs to show.

SOC 2 Type I

A Type I report assesses control design and implementation as of a specified date. Relevant pentesting evidence here might show that a testing control has been designed, a testing policy exists, defined roles and responsibilities are documented, and findings enter a defined remediation process. A recent pentest is useful for Type I, but it is not automatically mandatory.

SOC 2 Type II

Type II assesses whether relevant controls operated effectively over a defined review period, which changes what an auditor looks for. Auditors may examine whether testing occurred according to the company’s stated cadence, whether it fell within the review period, whether major findings were escalated and retested, and whether management reviewed the results and any significant environmental changes during the period. A company can create its own audit problem by claiming, say, that it performs annual pentesting and then failing to do so, since the control language, testing frequency, and actual evidence all need to agree.

How Frequently Should Testing Be Performed for SOC 2?

SOC 2 does not prescribe one universal pentesting frequency. Annual testing remains common anyway. It matches many audit cycles, customers often expect a report issued within the past twelve months, and it gives management a recurring assessment of technical risk.

That said, frequency should be based on a broader set of risk factors than a fixed calendar date.

• The organization’s own written testing policy and documented cadence.
• The rate of application change and exposure of internet-facing assets.
• Previous findings and how quickly they were remediated.
• Customer and contractual requirements that specify testing frequency.
• Regulatory obligations that apply to the organization’s industry.
• Acquisitions, cloud migrations, and infrastructure changes that expand the attack surface.
• Auditor expectations tied to the applicable review period.

Additional testing after major releases, new APIs, cloud migrations, or new AI features often closes the gap an annual schedule leaves open. None of this means post-change testing is mandated by SOC 2 itself, only that it supports the controls already written down.

What Should Be Included in the Testing Scope?

The scope needs to connect directly to the SOC 2 system description and the organization’s actual attack surface, covering production environments as well as the systems that could provide an indirect path into them. A short scoping checklist, grouped by category, helps keep this concrete before fieldwork starts.

System alignment confirms the scope matches what the SOC 2 report actually describes.

• Confirm which systems appear in the SOC 2 system description and which process customer data.
• Inventory relevant domains, subdomains, and cloud configurations.
• Identify systems supporting security or availability commitments described in the report.

Attack-surface alignment makes sure testing covers where the real risk sits, not just the easiest targets.

• Include APIs, administrative interfaces, and authenticated user roles, not just the public front door.
• Cover sensitive-data workflows, segmentation controls, and AI or LLM-enabled functionality where applicable.
• Include internal infrastructure and trust relationships, and any systems that could provide an indirect attack path into the in-scope environment.

Audit alignment connects the technical scope back to what the auditor will actually ask about.

• Document exclusions and the reasoning behind each one.
• Confirm that the test timing aligns with the organization’s documented control cadence, the applicable SOC 2 review period, and the auditor’s expectations.

A generic external network test is rarely sufficient for a SaaS provider whose most significant risk sits inside authenticated workflows and APIs rather than the network perimeter.

What Do Auditors Expect From the Testing Provider?

Auditors may review whether the testing resource appears competent and independent from the teams that built or operate the systems in scope. Depending on the organization’s control language and the nature of the evidence, an auditor may consider the provider’s competence, methodology, and organizational independence.

Relevant factors typically include the following.

• Methodology, and whether it follows a repeatable, documented process.
• Provider or tester competence and relevant technical experience.
• Quality assurance around how findings are validated before they reach a report.
• Secure evidence handling throughout the engagement.
• A clear severity methodology used to rate findings.
• Documented rules of engagement agreed before testing begins.
• Remediation and retesting support once findings are reported.

SOC 2 does not require a specific tester certification, so auditors instead look at supporting documentation: provider credentials, a statement of work, scope documentation, rules of engagement, and a retest report that together establish that the testing resource was qualified and appropriately independent.

Vulnerability Scanning vs Penetration Testing for SOC 2

These two activities get confused constantly, and the confusion causes real audit problems. The table below lays out the difference.

Vulnerability scanning	Penetration testing
Identifies known or suspected technical weaknesses	Tests whether weaknesses can actually be exploited
Usually highly automated	Combines tools with adversarial human analysis
Can run frequently at low cost	Usually performed during defined windows or continuously through PTaaS
Often produces unvalidated findings	Should provide evidence of real exploitability
Useful for broad vulnerability management	Useful for validating attack paths and control effectiveness

NIST SP 800-115 distinguishes vulnerability-identification and analysis techniques, including scanning, from techniques used to validate whether vulnerabilities can be exploited. SOC 2 does not universally say a scan is insufficient and a pentest is mandatory. Scanning alone often leaves the harder questions unanswered, since it rarely shows whether vulnerabilities can be chained together or whether an authenticated user can escalate privileges.

Teams weighing vulnerability scanning and penetration testing usually land on using both, just for different parts of the environment.

What Should a SOC 2 Penetration Testing Report Contain?

An auditor-oriented report needs executive information, including the test date, testing period, systems tested, provider identity, and a summary of material findings and business impact. It also needs technical detail: methodology, attack paths tested, vulnerabilities discovered, severity ratings, and recommended remediation.

Compliance and governance evidence rounds this out, covering scope approval, scope limitations and exclusions, asset inventory, provider qualifications, independence evidence where relevant, management review, and retest results. Evidence of exploitation and clear reproduction steps matter just as much as the summary findings, since an auditor reading the report needs to see how each finding was confirmed rather than assumed.

The clearest reports establish a visible evidence chain that runs from risk identified to status documented, and giving each finding a stable identifier that appears in the pentest report, the remediation ticket, and the retest result lets an auditor follow that chain without extra detective work.

Risk identified → Finding validated → Owner assigned → Action taken → Retest completed → Status documented

Risk-acceptance decisions and closure status for any exceptions or unresolved findings belong in the same package, so the auditor sees the full picture rather than only the findings that were fixed.

Do All Findings Need to Be Fixed Before the Audit?

Not necessarily, but every material finding needs an appropriate, documented response: remediation, a compensating control, formal risk acceptance, or a corrective action plan.

The organization should be ready to show how severity was assessed, who accepted any open risk, and why. Overdue issues that were never escalated usually draw more auditor attention than a documented, low-risk item in a constrained environment.

What Evidence Should Be Retained for the Auditor?

Organize evidence before fieldwork begins rather than scrambling for it afterward. A well-organized evidence set typically includes the following.

• The testing policy, risk assessment, and approved scope.
• The statement of work, rules of engagement, and provider qualifications, including independence evidence where applicable.
• The final report, executive summary, testing dates, and findings register.
• Remediation tickets, risk acceptances, and corrective-action plans for anything not immediately fixed.
• Retest results and evidence of closure, along with management-review evidence and records of any tests triggered by significant changes.
• Documented exceptions for findings that remain open at the time of the audit.

Giving each finding a stable identifier that carries through the report, the remediation ticket, and the retest result is worth repeating here, since this is the section where GRC readers most expect to find it. Evidence organized this way turns an audit conversation from a search exercise into a walkthrough.

Common SOC 2 Penetration Testing Mistakes

A handful of mistakes show up across most SOC 2 preparation cycles, and most of them are avoidable with a bit of planning before fieldwork starts.

Treating a Scan as a Pentest

An unvalidated scanner report is one of the most common substitutes for a real pentest, and it is one of the weakest. Scanner output alone rarely shows that controls resist actual exploitation, which is the evidence an auditor is looking for.

Testing the Wrong Environment

Testing a staging environment instead of production creates a gap between what was tested and what customers actually use, especially once the two environments have drifted apart over time.

Excluding APIs or Authenticated Workflows

This is particularly risky for SaaS companies whose sensitive functionality sits behind a login screen. A perimeter-only test misses exactly the part of the environment where the real risk usually lives.

Using a Stale Pentest

A pentest run before a major redesign no longer represents the current environment, and presenting it as current evidence can raise more questions than it answers.

Ignoring the System Boundary

A technically solid test that never maps back to the SOC 2 system boundary can still miss what the examination actually needs to see.

Failing to Document Exclusions

Leaving exclusions unexplained makes it harder for an auditor to judge whether the scope was reasonable or simply convenient.

Keeping Findings Outside the Remediation Program

Findings that live only in a pentest report, disconnected from ticketing and ownership, tend to stall. An auditor looking for a documented remediation process will not find one.

Failing to Retest

Closing a finding without confirming the fix worked leaves the organization guessing exactly where the auditor needs certainty.

Writing a Control the Company Cannot Consistently Perform

Promising a testing cadence the organization cannot reliably maintain creates its own audit problem, since the control language, the stated frequency, and the actual evidence all need to agree.

Where AI Penetration Testing Fits Into SOC 2 Compliance

AI-assisted penetration testing can help organizations expand attack surface discovery, test more assets, and retest remediated findings faster than a purely manual cycle allows. That expanded coverage helps organizations maintain more current security evidence between formal engagements.

Sara AI Pentesting can expand discovery and testing across the attack surface, while human researchers from the Synack Red Team validate complex and material findings. This combination helps security teams maintain actionable evidence without relying exclusively on a single annual testing window. AI-generated findings still need validation, and human expertise still matters most for business logic flaws and complex attack chains. AI testing on its own does not automatically produce SOC 2 compliance.

Teams exploring how automated penetration testing fits into an existing program tend to start with the assets that change most often, since that is where an annual test ages fastest.

Why Annual Testing May Leave Evidence Gaps During Type II

An annual pentest can support a testing control, but it rarely captures assets deployed after the test, new APIs, or vulnerabilities created during the rest of the observation period. None of this means continuous pentesting is universally required for SOC 2.

Continuous or on-demand testing can supplement a formal annual assessment by helping the organization produce more current evidence throughout the Type II review period. Continuous security validation combines ongoing testing with human expertise to keep pace with environments that change weekly rather than annually.

How to Choose a Penetration Testing Provider for SOC 2

A handful of criteria separate a workable engagement from a wasted one, and it helps to look at them individually rather than as one bundled checklist.

Alignment With the System Boundary

The provider’s proposed scope should map directly to the systems described in the SOC 2 report, not a generic template scope.

Testing Depth

Coverage should extend across web, API, cloud, and infrastructure rather than stopping at the network perimeter.

Validated Findings

A clear separation between confirmed, exploitable findings and raw automated noise makes the report usable as audit evidence.

Reporting

The report needs both executive summary content for auditors and technical detail for engineering teams to act on.

Retesting

A provider that cannot confirm a fix worked leaves the organization guessing, so retesting matters just as much as the initial engagement.

Testing Flexibility

The ability to test after major releases, not only once a year, keeps evidence current throughout the Type II period.

Evidence Management

A platform that tracks finding status from discovery through closure makes the audit conversation far easier to walk through.

Human Expertise

Automated tools miss business logic flaws and complex attack chains that require a skilled person to find and confirm.

Auditor Coordination

A provider that can produce documentation auditors actually recognize saves time compared with reformatting a generic report after the fact.

How Synack Supports Penetration Testing for SOC 2 Programs

The Synack platform combines Sara AI Pentesting with human validation through the Synack Red Team across web, API, cloud, mobile, and infrastructure systems, producing validated findings, centralized dashboards, and audit-ready reporting that can extend beyond a static annual engagement.

Synack does not guarantee SOC 2 compliance, and using Sara does not automatically satisfy the Trust Services Criteria. What the platform supports is audit preparation itself: technical control evidence, validated exploitable risk, and testing evidence maintained throughout the audit period.

See how Synack supports SOC 2 security validation. Get a personalized walkthrough of Sara AI Pentesting, human-validated findings, remediation tracking, and audit-ready reporting. Request a Demo.

SOC 2 Penetration Testing Checklist

A short checklist before, during, and after the test keeps most SOC 2 preparation cycles on track.

• Before: review the current system description, confirm Trust Services Categories in scope, coordinate expectations with the auditor, and confirm provider qualifications and independence.
• During: confirm the approved scope, test authenticated workflows and APIs, escalate severe issues fast, and record evidence and reproduction steps.
• After: assign remediation owners, create traceable tickets, retest corrected findings, record management review, and map the evidence to the organization’s actual controls.

Treat this less as a one-time exercise and more as a cycle that repeats every review period.

Conclusion

SOC 2 does not impose one identical pentesting requirement on every service organization, but auditors still need credible evidence that applicable security controls actually work. The test should match the system boundary, the risk assessment, and the control language already on record, and remediation and retesting matter just as much as the original report.

A pentest should provide more than an annual report. It should give security and compliance teams validated findings, traceable remediation, and evidence they can use throughout the SOC 2 examination period.

See how Sara AI Pentesting and the Synack Red Team help organizations continuously identify, validate, and prioritize exploitable risk. Request a Demo

This article is for informational purposes only and does not constitute legal or audit advice. SOC 2 evidence requirements vary by organization, applicable controls, and CPA firm. Confirm proposed testing scope, timing, and evidence directly with your auditor before fieldwork begins.