SOC 2 Penetration Testing for Bay Area SaaS Companies

If you are building a SaaS company in San Francisco, the South Bay, or anywhere along the Peninsula, SOC 2 compliance is not an abstract future concern. It is the thing blocking your next enterprise deal. And within SOC 2, penetration testing is the piece that causes the most friction — either because founders put it off too long, or because they run the wrong kind of test and have to redo it during the audit. This guide covers what Bay Area SaaS companies specifically need to know about SOC 2 penetration testing: the trust criteria it satisfies, how to scope it correctly, common mistakes Silicon Valley startups make, a realistic timeline, and what it actually costs.

Why Enterprise Buyers Demand SOC 2

SOC 2 has become the de facto security credential for B2B SaaS in the United States. A few years ago, an enterprise security questionnaire might have been enough to move a deal forward. Today, procurement and vendor risk teams at mid-market and enterprise companies — especially in financial services, healthcare, and technology — require a current SOC 2 Type II report before a contract goes to legal review. This is not negotiable at most companies above $1 billion in revenue.

The driver is accountability. A SOC 2 Type II report tells a prospective customer that an independent CPA firm examined your security controls over a defined observation period — typically 12 months — and found them to be operating effectively. A security questionnaire tells them you answered questions about your controls. The difference matters to enterprise risk committees.

For Bay Area SaaS companies, this pressure is particularly acute. San Francisco and Silicon Valley are home to a disproportionate share of the world's technology enterprise buyers. Your customers' security teams are sophisticated, your sales cycles are competitive, and a SOC 2 gap will show up in due diligence. Getting to Type II before your Series B is increasingly a precondition for landing the enterprise logos that justify that raise.

Penetration Testing as Evidence for CC6 and CC7

SOC 2 does not mention penetration testing by name anywhere in the Trust Services Criteria. This causes confusion. Some founders interpret this to mean pentesting is optional. Their auditors will correct that interpretation.

The criteria that drive the auditor expectation of a pentest are in the Common Criteria (CC) for the Security trust service category, which is mandatory for every SOC 2 engagement:

• CC4.1 — Ongoing Evaluations: The entity selects, develops, and performs ongoing or separate evaluations to determine whether controls are present and functioning. A penetration test is the most direct evidence that your security controls were tested against real-world attack techniques — not just verified to exist on paper. Policy documents and configuration screenshots do not satisfy this the way a pentest report does.
• CC6.1 — Logical and Physical Access Controls: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. Penetration testing validates whether those measures actually stop an attacker, rather than just existing in configuration. Authentication bypass findings, privilege escalation chains, and broken access control issues all map directly here.
• CC6.6 — External Threats: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. External penetration testing — simulating an internet-based attacker — is the primary evidence for this criterion.
• CC7.1 — Vulnerability and Threat Detection: The entity uses detection and monitoring procedures to identify vulnerabilities and susceptibilities to newly discovered threats. A pentest validates that your detection tooling and processes catch what they are supposed to catch. It also surfaces vulnerabilities that automated scanning misses.
• CC7.2 — Monitoring for Anomalies: The entity monitors system components for anomalies indicating malicious acts. Pentest results demonstrate what a real attacker's activity looks like in your logs and whether your alerting fires.

When your auditor reviews your evidence for these criteria during a SOC 2 examination, a penetration test report is the expected artifact. Its absence does not mean you automatically fail, but it does mean the auditor will either issue a management letter comment or require alternative evidence that is harder to produce. In practice, the path of least resistance is to run an annual pentest, remediate findings, and present the report and remediation evidence to the auditor.

For a deeper breakdown of what auditors specifically review in pentest reports, see our guide on SOC 2 penetration testing requirements.

How to Scope a Pentest for SOC 2

Scoping a SOC 2 penetration test correctly is the single most important decision in the process. An under-scoped test will produce findings the auditor considers insufficient. An over-scoped test wastes budget on systems that are not in your SOC 2 boundary. The right scope is determined by your system description — the document in your SOC 2 report that defines the systems and services being examined.

What Should Always Be In Scope

For a typical Bay Area SaaS product, the following components should be in scope for the penetration test if they are referenced in your system description:

• Customer-facing web application: The core product your customers log into. Every major feature should be covered — authentication, authorization, data access, file upload, payment flows, administrative functions.
• API layer: REST or GraphQL APIs accessed by the frontend, mobile clients, or third-party integrations. This includes both authenticated and unauthenticated endpoints, OAuth flows, and webhook receivers.
• Admin portal: Internal tooling used by your team to manage customers, configure the system, or access customer data. Admin portals frequently have weaker access controls than customer-facing surfaces.
• External network perimeter: Internet-facing infrastructure — load balancers, VPN gateways, jump hosts, any publicly reachable services. This is the CC6.6 external threat surface.
• Cloud configuration review: If your system description includes AWS, GCP, or Azure infrastructure, the pentest scope should include a cloud configuration review — IAM policies, storage bucket permissions, security group rules, encryption configuration, logging settings. This is not the same as network testing and requires cloud-specific expertise.

Defining Your System Description First

If you have not yet written your system description, write it before you scope the pentest. The system description drives the audit scope, which drives the pentest scope. Many founders scope the pentest based on what they think is important and then discover during the audit that the system description covers additional components that were not tested. Get alignment with your auditor on the system description before you engage a pentest firm.

Common Pitfalls Bay Area Startups Hit

Having worked with dozens of Bay Area SaaS companies through their first and subsequent SOC 2 audits, certain mistakes appear repeatedly. They are preventable once you know to look for them.

Running a Vulnerability Scan and Calling It a Pentest

Automated vulnerability scanners — Tenable, Qualys, Nessus — produce reports that look like penetration test reports. They are not. Auditors know the difference. A vulnerability scan identifies known vulnerabilities in software versions and configurations. A penetration test involves a human tester actively attempting to exploit those vulnerabilities, chain them together to escalate access, and discover business logic flaws that scanners cannot find. Submitting a scanner report as your SOC 2 pentest evidence is a fast path to a management letter comment and a delayed audit report.

Scheduling the Pentest Outside the Audit Window

SOC 2 Type II examinations cover a defined observation period, typically 12 months. The pentest must fall within that observation period to serve as evidence for that audit. A test completed in January 2025 does not satisfy an auditor examining the period from April 2025 to March 2026. Schedule the pentest early enough in your audit period that remediation and retesting are complete before the examination closes. Leaving the pentest to the last quarter of the audit period leaves no room for remediation.

Not Tracking Remediation

A pentest report with critical and high-severity findings is expected — it means the test found something. What the auditor cares about is that you fixed it. The evidence they want is ticket-level remediation tracking: a Jira or Linear issue for each finding, assigned to an owner, with a due date, marked complete, and linked to a retest result confirming the fix. Saying "we fixed everything" without ticket evidence is not sufficient for a SOC 2 audit.

Using a Firm Without SOC 2 Experience

Not every penetration testing firm understands SOC 2 evidence requirements. A firm that does general security consulting may produce a technically excellent report that does not map findings to Trust Services Criteria, does not structure evidence in a way auditors expect, and does not include a retest cycle. Ask prospective firms explicitly whether their reports are structured for SOC 2 auditors, whether they map findings to TSC, and whether retesting is included in the engagement.

Underscoping Because of Budget Pressure

Penetration testing budgets are often negotiated down during cost-cutting exercises. The resulting scope is sometimes too narrow to satisfy the auditor. A web-app-only test when the system description includes APIs and cloud infrastructure produces an evidence gap. It is more cost-effective to scope the test correctly the first time than to run a supplemental test to fill gaps the auditor identifies.

Timeline: From Zero to SOC 2 Type II

The typical timeline for a Bay Area SaaS company starting from no compliance program to a SOC 2 Type II report is 9 to 12 months. Here is how the penetration testing milestone fits into that timeline:

The most common timeline mistake is starting the pentest in month 8 or 9 of the observation period. This leaves four to eight weeks for remediation and retest before the audit examines the period. Critical findings discovered in month 9 with 30-day remediation SLAs cannot be closed before the audit window. The auditor sees open critical findings. Schedule the pentest in the first half of your observation period.

If you are approaching an audit deadline and have not yet run a penetration test, see our guide on SOC 2 for startups timeline for how to compress the process without creating evidence gaps.

Cost Considerations for Bay Area Companies

Bay Area SaaS companies face a specific pricing dynamic in the penetration testing market. Local firms headquartered in San Francisco, Palo Alto, or San Jose price their services to cover regional costs. A web application and API engagement from a Bay Area firm typically runs $18,000 to $40,000 for a reasonably scoped SaaS product. Adding cloud configuration review pushes that higher.

Remote-first penetration testing firms deliver work of equivalent — and often superior — technical quality at significantly lower price points because they are not carrying Bay Area office overhead or Bay Area salary costs. The same engagement scope runs $8,000 to $20,000 with a remote-first provider. The deliverable is the same: a formal report, finding severity ratings, remediation guidance, and a retest cycle.

Here is a realistic cost breakdown for a first-time SOC 2 Type II at a Bay Area SaaS company:

The savings from choosing a remote-first pentest provider are real and meaningful for a startup managing burn rate. The money saved is better spent on fixing the vulnerabilities the test finds, not on someone else's commercial office lease in SoMa.

For a full breakdown of what drives pentest pricing, see our guide on transparent pentest pricing.

What to Look for in a SOC 2 Pentest Provider

Selecting the right penetration testing firm for your SOC 2 is a vendor risk decision. The wrong firm produces a report that creates more problems than it solves. When evaluating providers, look for the following:

• SOC 2-specific report structure: The firm should produce reports that map findings to Trust Services Criteria by default, not as an add-on. Ask to see a redacted sample report.
• Retest included: Retesting critical and high findings within the same engagement should be standard. Firms that charge separately for retesting are incentivized to find more findings, not to help you close them.
• Auditor familiarity: The firm should understand what SOC 2 auditors look for and be willing to answer auditor questions directly if needed. Some firms provide a brief letter or attestation alongside the report confirming engagement scope.
• SaaS and cloud expertise: Your product runs on AWS or GCP. The tester should have demonstrated experience with SaaS application security, API security, and cloud configuration review — not just network penetration testing.
• Clear methodology: The firm should be able to explain whether they use manual testing, automated tools, or a hybrid approach, and how they prioritize testing effort across the scope. A primarily automated approach will miss the business logic vulnerabilities that are most common in SaaS applications.

View our full penetration testing services for Bay Area companies, or start a PTaaS engagement if you need ongoing testing coverage that keeps pace with your development cycle.

Continuous Testing After Your First SOC 2

Your first SOC 2 Type II is the beginning of an annual cycle, not a one-time project. Every subsequent audit period requires a new penetration test within the observation window. Bay Area SaaS companies that ship code weekly or daily face a growing gap between annual penetration tests. A vulnerability introduced in month 2 of the audit period could remain undetected for 10 months if you only test annually.

Penetration Testing as a Service (PTaaS) addresses this by providing ongoing access to a testing team that retests as your product changes. Rather than scheduling a one-time engagement once per year, you engage a team that tests new features, significant infrastructure changes, and API additions as they deploy. The annual report for the auditor covers a continuous testing program rather than a single point-in-time assessment. Auditors view this favorably.

For companies at Series B and beyond with significant engineering velocity, continuous testing is often the more practical approach to satisfying CC7.1 and CC7.2 across the full audit period.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.