Direct answer: SOC 2 does not universally require every company to complete a penetration test. However, penetration testing may be appropriate based on your risks, controls, policies, contractual commitments, auditor expectations, and customer requirements. For many B2B SaaS companies, a recent independent penetration test is also an important enterprise sales requirement.
SOC 2 and penetration testing answer different questions. A SOC 2 examination evaluates whether controls relevant to the selected Trust Services Criteria are suitably designed and, for a Type 2 report, whether they operated effectively during the review period. A penetration test evaluates whether a qualified tester can find and exploit weaknesses within an agreed technical scope.
One does not replace the other. Together, they provide buyers with evidence that your security program is documented, operational, and technically tested.
Does SOC 2 require penetration testing?
The AICPA Trust Services Criteria do not contain a universal rule stating that every SOC 2 engagement must include an annual penetration test. SOC 2 is risk-based, so organizations implement controls appropriate to their systems, commitments, risks, and selected criteria.
A penetration test can still become necessary when:
- Your risk assessment identifies application, API, network, or cloud threats that require independent testing
- Your policies or control descriptions commit the organization to periodic penetration testing
- An auditor expects evidence supporting your vulnerability management or security monitoring controls
- A contract, cyber insurance policy, customer, or regulatory obligation requires testing
- Your organization needs independent validation after a material product or infrastructure change
The founder-level takeaway
Do not claim that a penetration test is always mandatory for SOC 2. Instead, determine whether testing is required by your risks, documented controls, customers, contracts, and auditor. In practice, enterprise buyers frequently request both a SOC 2 report and recent penetration-testing results.
SOC 2 and penetration testing compared
| Comparison | SOC 2 examination | Penetration test |
|---|---|---|
| Primary purpose | Evaluate controls relevant to security, availability, processing integrity, confidentiality, or privacy | Identify and validate exploitable technical weaknesses |
| Performed by | An independent licensed CPA firm | Qualified internal or external security testers |
| Scope | The service organization’s defined system and applicable controls | Specified applications, APIs, networks, cloud environments, or other assets |
| Typical output | A restricted-use SOC 2 report | A technical findings report, executive summary, and often a retest report |
| What it demonstrates | Control design and, for Type 2, operating effectiveness over a period | Whether weaknesses could be exploited within the agreed scope and test conditions |
Vulnerability scanning is not penetration testing
Automated vulnerability scanning identifies known weaknesses, missing patches, insecure configurations, and exposed services. It is valuable for recurring monitoring, but it does not provide the same depth as a human-led penetration test.
A penetration tester can combine weaknesses, test business logic, evaluate authorization boundaries, and explore attack paths that an automated scanner may not recognize.
| Activity | Vulnerability scan | Penetration test |
|---|---|---|
| Primary method | Automated detection | Human-led testing supported by tools |
| Best use | Frequent identification of known issues | Validating exploitable paths and complex weaknesses |
| Business logic testing | Limited | Can be included in scope |
| Recommended role | Recurring security hygiene | Periodic independent assurance and targeted validation |
When should a startup complete its first pen test?
The right timing depends on product maturity, risk, customer expectations, and upcoming sales opportunities. A startup should consider scheduling its first professional test when the product is stable enough to evaluate and one or more of the following conditions applies.
Enterprise demand
Prospects are requesting a report, executive summary, attestation letter, or remediation evidence.
Material risk
The product handles sensitive information or exposes high-impact applications, APIs, or cloud services.
Major change
The company has launched a significant feature, changed architecture, or substantially expanded the testing scope.
Do not wait until a strategic customer gives you a short deadline. Scoping, testing, reporting, remediation, and retesting all require time. Begin planning early enough to correct meaningful findings before the report is shared with buyers or reviewed during audit preparation.
How to scope a useful penetration test
A low-cost test with the wrong scope can create a report that does little for security, compliance, or sales. Start with the assets that expose customer data or create the greatest business risk.
A SaaS penetration test may include:
- Customer-facing web applications
- Public and authenticated APIs
- Mobile applications
- External network infrastructure
- Cloud configurations and attack paths
- Authentication, authorization, and tenant isolation
- Business logic and privilege escalation scenarios
Define testing boundaries, accounts, environments, prohibited actions, communication procedures, and reporting expectations before work begins. If your application is multi-tenant, ensure authorization and tenant-isolation testing are explicitly included rather than assumed.
What should a startup receive?
A professional engagement should produce enough information for engineers to remediate findings and for leadership to understand business risk.
- An executive summary describing the scope and overall results
- Testing methodology and dates
- Detailed findings with evidence and reproduction steps
- Severity ratings and practical remediation guidance
- Clear scope limitations and testing assumptions
- A retest result showing whether remediated findings were resolved
Because a detailed report may contain sensitive attack information, many companies provide prospects with a sanitized executive summary, attestation letter, or report under a nondisclosure agreement instead of distributing the full technical report broadly.
How often should penetration testing occur?
Annual testing is common for SaaS companies, but frequency should be driven by risk and commitments rather than habit alone. Additional testing may be appropriate after major architectural changes, significant releases, acquisitions, new high-risk integrations, or security incidents.
If your policy promises annual testing, the company should either perform it annually or formally revise the policy through its approved governance process. Your written commitments must match your actual operating practice.
What founders should do before the test
- Confirm the assets and testing methods included in scope
- Assign a technical contact who can answer questions quickly
- Resolve obvious scanner findings before human testing begins
- Back up critical systems and establish emergency contacts
- Agree on testing windows and rules of engagement
- Plan engineering capacity for remediation and retesting
- Confirm what customer-facing documentation will be provided
Frequently asked questions
Can we pass SOC 2 without a penetration test?
Potentially, yes. There is no universal penetration-testing requirement for every SOC 2 engagement. The answer depends on your risks, controls, policies, commitments, customers, scope, and auditor expectations.
Does a vulnerability scan count as a pen test?
No. Scanning is primarily automated and identifies known weaknesses. Penetration testing includes human analysis and attempts to validate exploitable attack paths within an approved scope.
Should a pen test happen before or after the SOC 2 audit?
It should happen early enough to remediate findings and satisfy the control cadence or audit evidence requirements applicable to your engagement. Coordinate timing with your compliance lead and independent auditor.
Does a clean pen test mean our application is secure?
No. Results apply to the agreed scope, testing period, available access, methodology, and system state. A test reduces uncertainty but cannot prove that no vulnerabilities exist.
Do we have to share the full report with customers?
Not necessarily. Many organizations provide an executive summary or attestation and share detailed reports only under controlled conditions. The appropriate approach depends on customer contracts and risk.
Authoritative resources
Connect your compliance and technical testing
SCI can help you build your SOC 2 program, define the right penetration-testing scope, remediate findings, and prepare clear evidence for auditors and enterprise buyers.
Talk to an expert →Explore SOC 2 compliance or penetration testing.