Learn about SOC 2 penetration testing requirements and how to improve your company’s security posture against cyber threats. This article will continue to be updated with new requirements for 2026, should they come into force.

If you’re looking for a SOC 2 compliance pentest, we’re offering 15% OFF this month on our penetration testing services package tailored for SOC 2 audits.

Your organization is going through a long compliance journey, and you’re probably asking yourself: What are the SOC 2 penetration testing requirements, and does SOC 2 require vulnerability scanning or penetration testing for an audit?

The short answer is no. SOC 2 does not explicitly require penetration testing. It also does not explicitly require vulnerability scanning.

The practical answer is more nuanced. Auditors often expect evidence that your organization can identify vulnerabilities, test security controls, remediate weaknesses, and protect the systems that store or process customer data. For many SaaS, fintech, healthcare, cloud, and technology companies, a SOC 2 pentest is one of the clearest ways to provide that evidence.

This article explains how penetration testing and vulnerability scanning fit into SOC 2, how they map to AICPA’s Trust Services Criteria, and what your organization should prepare before the audit.

SOC 2 pentest requirements: quick answers

What is SOC 2 compliance?

SOC 2 is a set of standards that organizations must adhere to in order to ensure that policies and practices are in place to enhance the security of their systems and data. The American Institute of Certified Public Accountants (AICPA) oversees the framework.

To become SOC 2 compliant, organizations must have comprehensive policies and procedures to manage cybersecurity risks. They must also undergo regular independent audits to ensure their systems have adequate security measures.

SOC 2 is especially important for companies operating in the SaaS space because customers, partners, and procurement teams often rely on SOC 2 reports before approving a vendor. In many cases, presenting a SOC 2 report can determine whether a deal will go through, underscoring its importance to many organizations, as it directly impacts revenue and trust.

Key differences between SOC 2 Type I and Type II

There are two types of AICPA SOC 2 attestation reports: Type I and Type II. The difference between them is the following:

• SOC 2 Type I: reports on an organization’s information security controls at a specific time. The idea is to identify the controls and whether they are fit for purpose and in place.
• SOC 2 Type II: reports on an organization’s security controls over a period of time (3-12 months). The main goal is to determine whether the controls work as intended and fulfill the requirements of the AICPA’s Trust Services Criteria. They are more comprehensive and valuable for customers assessing an organization’s long-term commitment and strategy regarding cybersecurity.

For a Type I audit, a pentest may help demonstrate that your company has evaluated its systems in a timely manner. For a Type II audit, timing matters more because the auditor is looking at how controls operated during the audit period.

A practical approach is to perform the penetration test early enough to fix important findings before evidence collection becomes stressful. If the assessment finds a serious authorization flaw, exposed cloud secret, or vulnerable API, you want time to remediate it and validate the fix.

What are the AICPA’s SOC 2 Trust Services Criteria?

The AICPA’s SOC 2 Trust Services Criteria consists of five fundamental principles that guide organizations in securely managing and protecting data in compliance with relevant standards:

• Security
• Availability
• Processing integrity
• Confidentiality
• Privacy

Security ensures protection against unauthorized access and threats. Key measures include access controls, encryption, network security, vulnerability management, and incident response plans.

Availability guarantees systems and services are operational and accessible. This involves redundancy, disaster recovery planning, capacity management, and meeting service level agreements (SLAs).

Processing Integrity ensures data is processed accurately, completely, and on time. This includes data validation, error handling, system monitoring, and controlled process changes.

Confidentiality protects sensitive information from unauthorized access. Key practices involve data classification, encryption, strict access controls, and secure data retention and disposal.

Privacy governs the responsible handling of personal information and aligns with applicable laws and privacy notices. It covers notice and consent, data minimization, respecting individual rights, third-party disclosures, and privacy impact assessments.

Penetration testing usually supports the Security category most directly, but a well-scoped SOC 2 pentest can also provide useful evidence for confidentiality, availability, and privacy-related controls depending on the systems tested.

SOC 2 penetration testing and vulnerability scanning: what are they?

Penetration testing and vulnerability scanning are two critical elements used to assess the security of a computer system, verify an organization’s overall security posture, and test the controls designed to protect against cyberattacks.

Also known by the short form “pentest”, penetration testing involves a simulated attack using the same tools, tactics, techniques, and procedures as an adversary for purposes of ethical security testing. The intention is to identify vulnerabilities and exploit weaknesses to compromise and demonstrate impact on a particular system, a network, or an entire organization.

Impact demonstration can take different forms, such as gaining access to confidential assets, such as customer data or strategic, board-level sensitive information.

Conversely, vulnerability scanning is an automated process that attempts to identify known vulnerabilities and can indicate a company’s security posture.

Penetration testing and vulnerability scanning can help identify security risks, but they have different strengths and weaknesses. A penetration test is more likely to find unknown vulnerabilities, but it is more time-consuming and expensive. Vulnerability scanning is less likely to find vulnerabilities that do not follow known patterns, but it is much quicker and cheaper.

Is penetration testing a requirement for SOC 2?

The answer is no. While penetration testing can be valuable for any organization, it is not required to achieve or attain SOC 2 compliance.

However, auditors often recommend pentesting assessments to augment the audit and fulfill certain items in the Trust Services Criteria, especially those related to monitoring activities.

Two references matter here:

• COSO Principle 16: “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”
• CC4.1’s point of focus: “Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certifications made against established specifications (for example, ISO certifications), and internal audit assessments.”

The criteria mention pentest for SOC 2, suggesting that it can be one method used to perform the required evaluations. In other words, a penetration test augments your audit and helps achieve CC4.1, but it is not mandatory.

In our experience, even a customer’s public bug bounty program was once accepted by an auditor as evidence to meet CC4.1. It is all open to interpretation, but penetration testing can undoubtedly satisfy this requirement. It has the added benefit of discovering risks your organization might be exposed to and improving your resilience against cyber attacks.

Does SOC 2 require vulnerability scanning?

The short answer is no; SOC 2 compliance does not require vulnerability scanning, but it is recommended as best practice for any robust cybersecurity program.

Despite not being mandatory, vulnerability scanning can help satisfy the following requirements from the Trust Services Criteria, especially System Operations:

• CC7.1: “To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities”
• CC7.1 point of focus: “Conducts Vulnerability Scans — The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis”

Vulnerability scanning supports achieving CC7.1 but is not required.

Companies should consider incorporating regular vulnerability scans into their security practices. According to Automox, vulnerabilities resulting from failing to keep systems up to date and from a lack of timely patching are considered the root cause of 60% of data breaches.

How pentests support SOC 2 audit evidence

A SOC 2 pentest does not replace policies, risk assessments, access reviews, monitoring, incident response, or vulnerability management. It supports them by showing that selected controls were tested in practice.

This is where the audit conversation becomes more concrete. Instead of only saying, “we have access controls,” a pentest can show whether those access controls prevent a normal user from reaching another customer’s data. Instead of only saying, “we monitor for threats,” a pentest can help validate whether suspicious activity is logged, alerted on, and investigated.

This mapping matters because auditors rarely care about a pentest as a standalone document. They care whether the test supports the controls in scope, whether the tested systems match the SOC 2 system boundary, and whether your company acted on the results.

Should my organization perform SOC 2 penetration testing and vulnerability scanning as part of my compliance audit?

Indeed, penetration testing and vulnerability assessments are not required to achieve SOC 2 compliance. Nevertheless, they can be essential to an organization’s cybersecurity efforts, bolstering resilience and strengthening defenses against ransomware, data breaches, and other emerging threats affecting businesses worldwide.

Vulnerability scanning and penetration testing can help you assess the effectiveness of your security controls and identify areas where your IT security needs improvement. Used together, they form an important part of a comprehensive security program. Vulnerability scanning gives you continuous or recurring visibility into known issues, while penetration testing gives you deeper insight into exploitability, business logic flaws, and real-world attack paths.

For most SaaS and cloud companies pursuing SOC 2, the practical path is straightforward: run recurring vulnerability scans, perform at least one annual penetration test, remediate or accept the risk of the findings, and keep evidence that the process happened.

My organization decided to perform a pentest as part of our SOC 2 audit. What else do I need to know?

First of all, congratulations. A penetration test is a vital step in ensuring your organization’s security and helps you comply with SOC 2 standards.

The most important thing is scope. Your pentest should align with the systems included in your SOC 2 report.

If the SOC 2 system description covers your main SaaS product, APIs, administrative panels, cloud infrastructure, identity provider, Kubernetes clusters, mobile applications, or internal systems that support customer data, those assets should be considered when defining the penetration test scope.

This does not always mean testing everything at once. It does mean you should avoid testing a low-risk public website while leaving the systems that store, process, or protect customer data untouched.

It is also worth speaking with your auditor before finalizing the scope. The auditor should not design the pentest, but they can confirm whether the planned scope is likely to support the audit evidence they expect.

Defining the scope of the SOC 2 pentest

Defining the scope of a SOC 2 penetration test involves establishing the boundaries of what will be tested during the engagement. Typically, this includes a list of assets that the penetration testing team is authorized to evaluate and excludes those that are off-limits.

From our experience, organizations working toward SOC 2 compliance usually consider the following elements when determining the scope of their penetration test assessments:

• the company’s main product, particularly any user-facing SaaS or web platforms;
• administrative panels or internal tools that support the user-facing SaaS;
• APIs, such as REST, GraphQL, and microservices;
• public-facing server infrastructure, typically hosted in the cloud;
• security assessments of mobile applications, if applicable; and
• the company’s internal network, critical servers and infrastructure, which may include Active Directory, Kubernetes clusters, and similar systems.

Penetration tests are often conducted in a staging environment to prevent potential disruptions in production. As long as the staging environment closely mirrors the production setup, this approach is generally acceptable and widely used. However, consulting with your SOC 2 auditor beforehand is advisable to ensure that the scope meets their expectations.

A common mistake is scoping the pentest too narrowly. If your SOC 2 scope includes your SaaS platform, APIs, and cloud infrastructure, a pentest of only your marketing website will not provide the auditor with much useful evidence.

The average duration of a SOC 2 pentest

The typical SOC 2 penetration test timeframe varies depending on the project’s scope, ranging from 5 to 25 person days. Cybersecurity assessments for a single website or web application may take a few days, while large cloud infrastructures or intricate SaaS platforms might require several weeks. Most penetration tests for SaaS companies are completed in one to two weeks, though larger scopes may take longer.

Beware of providers offering “express” penetration tests lasting one to three days, as these assessments likely rely on automated scanners or basic checklists without sufficient attention to detail. Consequently, such tests may miss subtle vulnerabilities, especially in an application’s business logic.

In our experience, a SOC 2 penetration test that takes less than 40 hours to complete for a small- to medium-sized scope may not provide sufficient scrutiny. A good engagement should leave enough time for planning, testing, reporting, remediation, and fix validation.

The estimated cost of a SOC 2 penetration test

The average estimated price for a SOC 2 pentest conducted by a credible, accredited cybersecurity firm may range from $5,000 to $25,000, depending on the scope and complexity. The price may be higher for more comprehensive security audits or lower for smaller scopes. Reputable penetration test providers often charge around $200 to $300 per hour.

Be cautious when considering providers with significantly lower prices, as they may rely solely on automated scanners or employ unqualified pentesters for such assessments. While such low-quality pentest reports might appease an auditor, they can create a false sense of security and leave systems vulnerable due to superficial evaluations.

When comparing providers, look beyond price. Ask whether the report includes business impact, reproducible findings, remediation guidance, executive summaries, attestation letters, and retesting. For SOC 2, the reporting and evidence package can be just as important as the testing itself.

Final remarks

SOC 2 can be a valuable tool for organizations looking to enhance their information security procedures, protect customer data, and demonstrate that robust controls are in place.

Penetration testing and vulnerability scanning are essential for assessing an organization’s systems and data security. However, neither pentests nor vulnerability scans are mandatory for SOC 2 compliance. When used as part of a SOC 2 compliance audit, they can help identify potential risks and vulnerabilities, ensuring that appropriate controls are in place to mitigate those risks.

Whether to include penetration testing and vulnerability scanning in a SOC 2 audit should be based on each organization’s specific risk profile, needs, and security objectives. Providing pentesting reports and evidence of periodic vulnerability scans will make your audit experience smoother and give the auditor greater confidence in your organization’s cybersecurity practices.

If your company is considering penetration testing or vulnerability scanning as part of your SOC 2 audit process, contact us to discuss your needs and how our penetration testing-as-a-service offering can help your organization.

If you want to learn more about the topic, we recently published the complete buyer’s guide to SOC 2 penetration testing. It contains everything you need to know about pentesting for SOC 2 compliance.

FAQ