SOC 2 Penetration Testing: Is It Required for SOC 2 Compliance?

The AICPA does not require SOC 2 service auditors to perform penetration testing; however, it expects management to ensure that all applicable security requirements are met. Auditors generally identify any deficiencies in compliance with these requirements.

From a management perspective, gaps in understanding SOC 2 requirements may arise when leadership is informed that a particular control is unnecessary. Management may then decide to omit the control; however, auditors may still request evidence that it has been implemented.

It’s helpful for both management and auditors to have a clear understanding of their responsibilities. This resource offers guidance to both groups, with examples that show the difference between sufficient and insufficient SOC 2 penetration testing and explain how to align testing with Type 1 and Type 2 reports.

What Does the Trust Services Criteria Say About Pentesting 

The security requirements outlined in the AICPA’s Trust Services Criteria are explained, giving reviewers a clear understanding of what auditors expect. The outcomes of the trust service criteria tend to progress with a broader scope that needs to be achieved. The criteria do not require the commission of a penetration test.

Meeting the criteria requires establishing controls and validating their effectiveness. This may be evidenced in several ways, including by commissioning a penetration test. A penetration test is a common method of validating the effectiveness of controls.

The latest edition of the Trust Services Criteria was published in 2017, with revised points of focus issued in 2022.

Point of focus CC4.1, requires the assessment and evaluation of internal control procedures to determine their effectiveness. It provides an illustrative example of a penetration test.

Point of focus CC7.1 requires the assessment of systems to determine if there are any changes that may adversely impact the effectiveness of controls. It states that continuous monitoring is closely tied to vulnerability scanning.

Lastly, CC4.2 focuses on the identification and communication of control deficiencies.

A point of focus is illustrative, not evaluative. The AICPA has stated that the criteria do not require an assessment of points of focus.

Penetration testing is not explicitly required to satisfy CC4.1; however, it is permitted. If penetration testing is not conducted, an alternative method for evaluating the effectiveness of the security controls must be demonstrated.

As of October 28, 2026, the AICPA has issued Exposure Drafts of the 2027 Trust Services Criteria, with the public comment period open through January 15, 2027. If finalized, the changes will apply to attest engagements performed on or after December 31, 2027. As of this writing, the 2017 criteria remain the latest and best versions.  Explore the Core Principles of SOC 2 to understand the five Trust Services Criteria and their role in building customer trust.

Why Most SOC 2 Organizations Run a Pentest Anyway 

There are three main reasons for soc 2 penetration testing:

• Auditors expect evidence of independent testing.. Saying you test your security is not as strong as a report from testing, indicating that attempts were made to breach your security and the results.
• Clients ask for it. Every enterprise security questionnaire requests a recent third-party penetration test report, regardless of whether one is required for SOC 2.
• It is the cleanest answer to CC4.1. Sure, alternative approaches exist, but they are less well described and more vulnerable to attack.

Baker Tilly, a CPA firm, explains thatsoc 2 penetration testing isn’t specifically required, but is "recommended and often considered a best practice." That's how the market works.

Why SOC 2 Reports Without a Pentest Get Challenged in Security Reviews 

There are a few reasons why a service organization undergoing a SOC 2 engagement is challenged to provide a penetration testing report. Many of these challenges arise after the report has been issued. They come from readers outside the organization, including the service organization’s clients and prospects.

Without penetration-test evidence, a reviewer may ask, “How do you really know your controls would protect against an attacker?” The typical answer is, “A scanner tells us where the issues are, and we plan to address them.” Reports therefore likely include control-defect findings. The absence of a penetration test is unlikely to prevent issue or control section sign-off, but it may lead to negative audit remarks. Learn more about SOC 2 and understand how it helps organizations demonstrate the security and reliability of their systems.

What a Penetration Test Delivers Ahead of a SOC Audit 

Timely Execution to  avoid audit delays

Tests are often delayed or fail to cover the full scope required to address the “real” attack surface. Tests conducted during an audit may have an overly broad scope to help identify high-risk and critical issues, as well as control deficiencies.

Strengthening Audit Preparedness 

Testing may be conducted in advance to help identify, for example, unmanaged access controls and insecure interfaces. Testing may be coordinated with the auditors to assess control effectiveness; however, it should be conducted early enough to allow identified issues to be remediated through normal business processes (e.g., engineering change control).

Alignment With Key Trust Services Criteria 

Although a penetration test is conducted for a specific purpose, it may provide evidence that supports multiple criteria.

• CC4.1, CC4.2: A pentest evaluates controls and communicates evidence of deficiencies.
• CC6 series: A pentest evaluates controls for logical access and access control.
• CC7.1-CC7.4: A pentest evaluates controls and identifies vulnerabilities. Additionally, a pentest evaluates the monitoring and incident response processes.
• C1.1 (Confidentiality): A pentest evaluates controls to protect the confidentiality of the data.

As always, your auditor decides how to map it. A good report makes that decision easy.

What Auditors Look for in a Pentest 

An auditor is not concerned with your testers' ideation. An auditor assesses whether a pentest provides sufficient evidence. Evidence generally means that:

• Scope is everything inside your SOC 2 system boundary. Applications, infrastructure and external attack surface that support the in-scope service.
• Timing is within the audit window of (Type 2) or before the report date of (Type 1)
• A qualified tester who is not testing their own work.
• A proven process. Baker Tilly states this has been done following recognised standards like OWASP or NIST.
• Findings, severity ratings, and remediation, including evidence that high-severity items were closed or formally risk-accepted and retested.

Why Not All Penetration Tests Are Equal 

Given feasibility, various companies may conduct a penetration test. However, the scope and methodology of their assessments may differ significantly. These differences may determine whether a test passes or fails during a review. 

Network vs. Application Layer Testing 

Testing at the network layer verifies the configuration and installation of networking services and interfaces. Testing at the application layer verifies the configuration and installation of web services and interfaces. Web services and APIs at the application layer may have inadequate access controls. For a software-as-a-service (SaaS) product, defects at the application layer may pose a greater risk.

Internal vs. External Testing 

External testing focuses on functionality and the information available to untrusted users. Internal testing focuses on the impact of a security failure resulting from compromised trust. External testing is the bare minimum, while internal testing may be warranted when service functionality or availability could negatively affect the organization.

Automated Scans vs. Manual Testing 

In software development, regularly running automated tests is good practice. However, the impact of an application layer failure can vary depending on several factors. Manual testing can help evaluate these impacts and incorporate individual application layer failures into larger unit tests.

Vulnerability Scan vs. Automated Pentest vs. Human-Led Pentest 

The vulnerability scan vs. penetration test question comes up in nearly every audit. Here is how the three compare:

Programs that integrate all three services are best positioned to meet audit requirements. If a program can fund only one service to support CC4.1, it should fund the human-led service.

 

Key Factors When Choosing a Pentest SOC 2 

When considering SOC 2 pentesting vendors, consider the following:

• Will testing go beyond the scope of my SOC 2 system description?
• What type of manual/automated testing is performed?
• Do reported findings include the methodology and supporting evidence, and offer recommendations for remediation?
• Were any additional tests conducted to verify the remediation?
• Are they available to perform the test during your audit window?
• Will the vendor sign a letter of attestation?

Essential Contents of a SOC 2 Pentest Report

When reviewing a SOC 2 penetration testing report, look for the following elements:

• Executive summary readable by non-technical stakeholders
• Test dates to show they fall within the audit period
• Clear scope: systems, environments, IP ranges, applications, exclusions
• Methodology and standards applied (e.g. OWASP / NIST aligned)
• Tester name or firm, and qualifications
• Severity-rated results and evidence of exploitability
• Remediation recommendations
• Impacted assets and reproduction steps
• Retest results of fixed, open and accepted-risk items
• Limitations and any constraints on testing
• Attestation or summary letter for customer sharing

Pentest Timing for SOC 2 Type 1 vs Type 2 

The primary distinction between the two is the timing.

• A SOC 2 Type 1 report evaluates whether controls meet a specified set of requirements at a point in time. To achieve this objective, controls do not necessarily need to be in place when the report is issued.
• Tests performed under Type 2 assess a control’s effectiveness over a specific period, typically several months. To perform a Type 2 test, the test, along with remediation and retesting, must occur within the test window. Testing near the end of the window provides the least opportunity to demonstrate the effectiveness of controls and may require a waiver.

Run the test early in the window so there’s time for corrective action and a retest.

Additionally, a security controls assessment conducted as part of a SOC 2 audit may influence the design and/or implementation of controls, thereby strengthening the SOC 2 report.

Making a SOC 2 Pentest Strengthens Security, Not Just Closes a Deal 

A pentest done just to check a box ends up in the big filing cabinet. A valuable one makes a difference.

• Treat results as an engineering project with owners and a deadline
• Follow security bug reports in the same system as other issues
• Bring the root causes of these bugs into your secure development lifecycle
• Question what the test missed so that you can cover it next time.
• An auditor can typically spot the live process from the once-a-year PDF.

Recommended Pentest Frequency for SOC 2 

There are no specific SOC 2 requirements for how often testing must be performed. However, an accepted industry practice is to test annually. An assessment should also be performed if changes to the organization’s systems or infrastructure may affect its controls and safeguards. Accordingly, Baker Tilly recommends annual testing.

An organization may find it prudent to conduct testing more frequently than annually, in accordance with the practices and requirements established by its customers and regulators.

Intercert’s Approach to Pen Test for SOC 2

SOC 2 penetration testing can help you discover security flaws, assess the maturity of your security controls and the security posture of your organisation. SOC 2 penetration test is part of your security strategy: it helps you identify and address risks, adopt best practices, ensure confidentiality and grow confidence among users. 

Strengthen your SOC 2 readiness through practical penetration testing. Intercert offers CREST-accredited assessments aligned with applicable AICPA standards to help organizations demonstrate their commitment to protecting customer data and earning customer trust.

Ready to assess your mobile application's security? Contact INTERCERT to discuss your mobile application penetration testing requirements and take a proactive approach to security.