Although SOC 2 does not require penetration testing, security leaders should use it to validate whether the controls protecting their most critical systems can withstand real-world attacks. A well-scoped test can provide useful evidence for SOC 2 reporting while helping organization’s identify and address weaknesses before they affect customers. 

The right approach depends on the organization’s environment. For SaaS companies, that may mean testing application authorization, APIs, and tenant isolation. Organizations with significant internet-facing infrastructure may also need external network testing, while AI features, agents, copilots, and model integrations introduce additional attack paths that should be included in the scope. 

Auditors need evidence that vulnerability-management controls are operating effectively, and enterprise customers want confidence that identified issues have been remediated. Security leaders can make penetration testing a meaningful part of their broader security program by aligning it with the organization’s attack surface, release cadence, and risk profile. Remediation and retesting should be part of that process. 

How penetration testing supports SOC 2

SOC 2 evaluates controls against the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria. Security is included in every SOC 2 examination, with Availability, Processing Integrity, Confidentiality, and Privacy included according to the organization’s commitments and system requirements. Penetration testing can support that control environment by demonstrating how systems behave when testers actively attempt to bypass security measures and the evidence can take different forms depending on the examination: 

• Type I report: A recent penetration test can support evidence that relevant security activities have been established.  

• Type II examination period: Auditors may also examine how findings were tracked, whether remediation followed established vulnerability-management timelines, and whether fixes were validated.

That evidence can include the initial test report, remediation records, tracking tickets, and retest results. The retest is particularly important because it shows not only that an organization found an issue, but that it fixed the issue and confirmed the fix worked. 

Scope testing around the SOC 2 environment

A useful penetration-test scope begins with the systems and commitments represented in the SOC 2 environment. For many SaaS companies, they use the following types of testing: 

• Web application penetration testing carries significant weight because the application contains critical customer-facing security boundaries. Testing should cover authentication, APIs, authorization, business logic, and access controls. Multi-tenant platforms warrant particular attention to horizontal and vertical privilege escalation. Testers may receive accounts across separate tenants and roles and attempt to access another customer’s information or gain capabilities assigned to higher-privileged users. 

• External network penetration testing addresses internet-facing infrastructure, including exposed cloud services, storage, remote-access endpoints, and management interfaces. Additional testing may be appropriate for mobile applications, internal networks, or other components within the system boundary. 

AI/LLM, mobile application, and internal network penetration testing come into play depending on what your product does and how your environment is built. 

Include AI capabilities in the attack surface 

AI functionality increasingly sits inside applications covered by SOC 2 system descriptions. Chatbots may retrieve customer information, copilots may call internal services, and agents may invoke tools or take actions across connected systems. Testing these capabilities requires understanding the model’s access to data, APIs, tools, and downstream systems. Testers may evaluate prompt injection, sensitive-data exposure, output handling, tool permissions, and whether manipulated inputs can trigger unauthorized actions. 

Security leaders need to ask themselves, “What can the AI system access or do within the environment?” Those permissions and integrations should inform the penetration-test scope. As companies add AI functionality, their attack surface is changing faster than many annual testing schedules. Security teams should account for those changes before an AI feature becomes a new pathway to customer data or critical systems. 

Build remediation and retesting into the engagement 

The usefulness of a penetration test extends through remediation. Organizations should establish the retesting process before work begins. The final report should document the systems tested, methodology, findings, risk ratings, supporting evidence, and remediation guidance. After findings are addressed, retesting confirms whether the fixes hold. This creates an evidence trail that security and compliance teams can connect to vulnerability-management controls: what was tested, what was identified, how the organization responded, and whether remediation was validated. 

Independent testing can also strengthen the usefulness of that evidence for auditors and enterprise customers. When selecting a provider, organizations should consider the qualifications of the testers, relevant application and industry experience, methodology, and reporting practices. 

Align testing cadence with the environment 

Annual penetration testing remains common within SOC 2 programs. Security teams should also consider how frequently the attack surface changes. New APIs, major releases, acquisitions, cloud migrations, and AI integrations can materially alter the environment between annual assessments.  

A test performed once a year may satisfy a common audit expectation, but it may not reflect the risk of an environment that changes every week. Organizations with frequent releases may choose additional testing during the year or establish continuous coverage using automated tooling, AI-enabled testing techniques, and human-led assessment. 

A sound approach to penetration testing includes testing throughout the year, regular reporting, and clear documentation that supports SOC 2 evidence and customer security reviews. The appropriate cadence should align with release practices, risk assessments, vulnerability-management policies, and audit requirements. 

Make the penetration test useful beyond the report 

The central SOC 2 question is how penetration testing supports the controls and systems within the organization’s specific environment. For SaaS and technology companies, that can mean testing application authorization, tenant isolation, APIs, internet-facing infrastructure, and AI capabilities under realistic attack conditions.  

While SOC 2 does not explicitly require a penetration test, testing gives security leaders a clear view of whether their most critical controls can hold up against a real-world attack. Clear scoping, qualified testers, documented remediation, and retesting produce evidence that can serve security teams during the audit process and subsequent customer reviews.