31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
SaaS penetration testing: what to test, when a startup should start, and what enterprise buyers will ask for
A SaaS product carries every customer's data behind one codebase, one identity layer and one cloud account. The vulnerabilities that matter are the ones that let one tenant see another, let a user become an admin, or let a leaked token open the whole platform. This guide sets out what a SaaS penetration test should cover, how a startup sequences its first one, and what SOC 2 auditors and enterprise procurement teams expect to see afterwards.
Why SaaS is tested differently
A traditional web application test treats the application as a boundary: the attacker is outside, the data is inside. A SaaS platform has no such boundary. Every customer is already inside, authenticated, and sharing the same application servers, database clusters, object storage and identity provider as every other customer. The security question is therefore not only whether an outsider can get in, but whether an insider (a legitimate user of tenant A) can reach anything belonging to tenant B, escalate within their own tenant, or reach the platform layer that serves everyone. In our experience, the findings that cause the most damage in SaaS environments are authorisation failures, not injection: a predictable identifier, a missing tenant check on one of four hundred endpoints, or an OAuth flow that trusts a redirect URI it should not.
The second difference is velocity. SaaS teams deploy continuously, so the attack surface at the time of an annual test is not the attack surface a customer uses six months later. That shapes how the test is scoped (prioritise the authorisation model and the shared layers, which change least and matter most) and how often it is repeated. The third difference is that the test result is itself a product requirement: enterprise customers, SOC 2 auditors and cyber insurers will ask for it, and a well-scoped report is often what closes the first large deal.
The SaaS attack surface: what a test must cover
Six areas, in the order we usually prioritise them. Each maps to a class of real incidents.
Multi-tenant isolation
Can a user of one tenant read, modify or delete data of another? We test every object type and every endpoint with two tenants and swapped identifiers, including background jobs, exports, search indexes, webhooks and file storage paths, which are the places isolation is most often forgotten.
Authorisation and IDOR
Broken object-level authorisation (OWASP API Security Top 10 2023, API1) and broken function-level authorisation (API5): a viewer who can call an admin endpoint, a member who can change billing, an ID in a URL that is never checked against the session. This is where most critical SaaS findings come from.
SSO, OAuth and SAML
Enterprise customers insist on SSO, and SSO is where a single flaw affects every customer. We test OAuth 2.0 redirect URI validation, state and PKCE handling, token lifetimes and revocation, SAML signature validation and assertion handling, just-in-time provisioning, and whether a user can link an account to an identity provider they do not control.
API surface
The public API, the internal API the front end uses, mobile APIs, GraphQL endpoints, webhooks and partner integrations. Rate limiting, mass assignment, excessive data exposure, versioned endpoints that were never retired, and API keys with broader scope than the UI permits.
CI/CD and supply chain
Secrets in repositories and build logs, pipeline permissions that let a pull request reach production credentials, unpinned dependencies and container base images, and the path from a compromised developer laptop to a production deployment. Mapped to the OWASP Top 10 CI/CD Security Risks.
Cloud posture
IAM roles and policies, publicly readable storage buckets, metadata service exposure from the application tier, overly broad security groups, secrets managers, and whether a server-side request forgery in the application becomes a route to cloud credentials. Reviewed against the CIS Benchmarks for AWS, Azure or Google Cloud.
Penetration test, bug bounty and automated scanning for a SaaS company
The three are complementary. Confusing them is the most common mistake we see in early-stage security programmes.
| Aspect | Penetration test | Bug bounty programme | Automated scanning (DAST/SAST/SCA) |
|---|---|---|---|
| Coverage | Systematic, against an agreed scope and methodology | Opportunistic; researchers test what interests them | Broad but shallow; known vulnerability classes only |
| Authorisation and tenant logic | Core focus, tested with multiple roles and tenants | Sometimes found, rarely exhaustively | Not found; scanners do not understand your data model |
| Evidence for auditors and customers | Dated, scoped report with named testers; accepted by SOC 2 auditors and procurement | Not accepted as a substitute; useful as a supporting control | Supporting evidence for continuous monitoring, not a pentest |
| Cost model | Fixed scope, quoted per engagement or as a retainer | Pay per valid finding plus platform fee; unpredictable | Subscription per tool |
| When it fits | Before the first enterprise deal, before SOC 2, annually and after major changes | After the first pentest, once obvious issues are fixed | From the first commit, in the pipeline |
How a startup sequences its first penetration test
The right moment is set by customers and auditors, not by funding stage alone. This is the sequence that works for most B2B SaaS companies.
1. Pre-seed and seed: build the foundations, do not buy a pentest yet
At this stage a full penetration test finds issues you will refactor away in three months. Put dependency scanning and secret detection in the pipeline, enforce MFA on cloud, source control and identity provider accounts, write down your tenant isolation model, and threat-model the authentication and billing flows. Those steps cost little and make the first real test far more valuable.
2. First enterprise prospect or Series A: the first scoped test
The trigger is usually a security questionnaire from a prospect or the decision to pursue SOC 2. Commission a grey-box test of the web application and API with credentials for every role in at least two tenants, plus a cloud configuration review of the production account. Fix the criticals and highs, retest, and you have a report and an attestation letter that will carry you through procurement.
3. SOC 2 Type II: make it annual and tie it to change
Auditors expect to see a penetration test within the observation period and evidence that findings were remediated. Repeat the test annually and after material changes: a new authentication method, a public API launch, a new cloud region, an acquisition. Our SOC 2 penetration testing guide covers what the auditor will ask for.
4. Scale: continuous testing plus periodic depth
Once releases are weekly and the application count grows, move to a continuous testing retainer for the applications and APIs, keep an annual deep engagement for the cloud and identity layer, and consider a bug bounty programme once the obvious issues are gone. Add a red team exercise when you have a detection capability worth testing.
What enterprise procurement and SOC 2 auditors will ask for
Have these ready before the first security questionnaire arrives. They are the same items a SOC 2 auditor will request under CC4.1 and CC7.1.
- A penetration test report from the last 12 months, or a summary and attestation letter from the testing firm naming the testers, the methodology, the scope and the dates
- Evidence that critical and high findings were remediated and retested, with dates
- A scope statement showing the test covered the production application, its APIs and the authentication and authorisation model, not a staging copy of the marketing site
- Testers' qualifications (OSCP, OSWE, CREST) and independence from your engineering team
- The methodology followed: OWASP Web Security Testing Guide, OWASP API Security Top 10 2023, OWASP ASVS v5.0 as the verification standard, NIST SP 800-115 for the process
- Your vulnerability management policy and SLAs for remediation by severity, with the pentest findings as evidence the process works
- For customers in regulated sectors: whether the test covered the controls they inherit from you (encryption at rest and in transit, logging, tenant isolation, SSO enforcement)
- Standard questionnaire answers prepared in SIG and CAIQ v4 format so each enterprise deal does not restart the process
Scoping a SaaS penetration test well
The scope conversation determines most of the value. Give the testers credentials for every role in at least two separate tenants, including an owner or admin, a standard member and the most restricted role, so tenant isolation and privilege boundaries can be tested properly; a black-box test of a SaaS platform spends days on reconnaissance and finds a fraction of what a credentialed test finds. Include the public API and the internal API with their documentation, the SSO configuration with a test identity provider, the mobile application if you have one, and read access to the production cloud account for a configuration review. Name what is out of scope (payment processor pages, third-party embedded widgets) and agree how testing will avoid disrupting other customers: a dedicated test tenant in production is usually better than a staging environment that has drifted from it.
Ask the testing firm how findings will be classified. CVSS v3.1 or v4.0 is standard, but a SaaS company also needs a business-impact view: a medium-severity finding that exposes one tenant's data to another is a critical issue for your sales pipeline regardless of its score. Agree on same-day escalation of critical findings and on a retest window, and ask for an attestation letter as a separate deliverable from the report.
What to publish in your trust center
Enterprise buyers increasingly expect a trust center: a page or portal that lists your certifications, policies and testing evidence. Publish the attestation letter or an executive summary of the penetration test (scope, dates, methodology, tester qualifications, number of findings by severity, confirmation of remediation), not the full report. The full report contains reproduction steps and architecture detail that help an attacker; share it under NDA with customers who need it, through the trust center's gated request flow. Update the summary after each test and after the retest, so the published status reflects remediated findings rather than the initial count.
Pair the testing evidence with your SOC 2 report (gated), your ISO 27001 certificate if you hold one, your subprocessor list, your data residency statement and your vulnerability disclosure policy. Procurement teams that find all of that in one place approve vendors faster and ask fewer bespoke questions. Our guide to how often penetration testing should be performed sets out a cadence you can state publicly and keep.
How HackersHub tests SaaS platforms
Our SaaS engagements are led by OSCP-certified testers who have spent ten years finding authorisation and isolation flaws in multi-tenant applications. We test grey box, with roles across multiple tenants, against the OWASP Web Security Testing Guide and the OWASP API Security Top 10 2023, with a cloud configuration review of the production account and, where relevant, the CI/CD pipeline. Every finding carries evidence, a business-impact statement and specific remediation guidance for your stack; critical findings are escalated the same day. You receive the report, a retest after remediation, and an attestation letter signed by the lead tester that your SOC 2 auditor and your enterprise customers can rely on. Scope and effort are agreed in writing after a scoping call; we do not publish prices. For companies shipping weekly, the same team delivers continuous testing as a retainer.
Frequently asked questions
Preparing for your first enterprise deal or SOC 2 audit?
A 30-minute scoping call establishes the tenants, roles, APIs and cloud accounts to test and what your auditor and customers need to see afterwards. You receive a written scope, named OSCP testers and the attestation terms. Talk to an expert.