Penetration Testing for SaaS Companies
Why annual application testing is no longer enough.
SaaS organisations face a particular combination of attack surface, regulatory expectation and customer scrutiny that makes traditional annual penetration testing inadequate for managing real-world risk. The application is internet-facing by design. Deployment cadences are weekly or daily. Customer data sits in shared infrastructure. Buyers — particularly enterprise B2B buyers — routinely demand evidence of security assurance before signing.
This article covers the testing patterns we see working for SaaS organisations in 2026: what to test, how often, where the multi-tenant failure modes hide, and the kinds of evidence enterprise customers expect to see. The framing assumes you already operate a production SaaS product and are deciding how to structure ongoing security assurance, not whether to bother.
Why SaaS organisations attract attention
SaaS providers are attractive targets for several structural reasons:
- Concentration of sensitive data. A single SaaS application typically holds data for thousands of customer organisations. Compromise is multi-tenant by design, which is exactly what attackers want.
- Public exposure. The application, API, marketing site, support portal, status page and admin tooling are all reachable from the public internet. The attack surface is large and largely unavoidable.
- Integration complexity. SaaS products live inside webs of OAuth grants, webhook integrations, third-party APIs and shared identity providers. Each integration is a trust relationship that can be abused.
- Rapid change. Continuous deployment is a strength for product velocity and a challenge for security assurance. Code that was secure yesterday may have changed today.
- Customer expectation. Enterprise B2B customers expect specific evidence — SOC 2, ISO 27001, pen test letters, security questionnaires. Failure to produce them removes deals from the pipeline.
The combined effect is that SaaS organisations cannot rely on a once-a-year application test. The product changes, the integrations grow, and the customer base scales — all between engagements.
What to test, in priority order
A credible SaaS testing programme covers five distinct surfaces, in approximately this order of priority:
1. Application and API
The core product. Authenticated flows, business logic, session management, authorisation between user roles, and the underlying API behaviour. Broken Object Level Authorisation (BOLA) and Broken Function Level Authorisation (BFLA) remain the dominant high-impact findings; both require manual testing to surface reliably.
2. Multi-tenant boundaries
The single most undertested area in SaaS, and the single most damaging when it fails. Discussed in detail in the next section.
3. Cloud configuration
IAM policies, public storage, exposed services, network segmentation, secrets management, logging configuration. A misconfigured production AWS or Azure tenant can undo a flawless application security programme. Cloud configuration review is now a distinct discipline rather than a sub-discipline of pen testing.
4. Identity infrastructure
SSO, OAuth grants, MFA enforcement, account recovery, session lifetime, token handling. SaaS organisations now run identity at non-trivial scale, and identity failures are typically silent until exploited.
5. External infrastructure
The marketing site, status page, support portal, documentation site and any auxiliary services. These are not the product, but they are part of your brand’s attack surface, and a compromised marketing CMS that hosts customer-bound JavaScript is a material incident.
The multi-tenancy problem specifically
Multi-tenant isolation is the area where SaaS organisations most consistently underinvest in testing, and the area where consequences are most severe. The technical patterns vary — row-level tenant filtering, per-tenant schemas, per-tenant databases, per-tenant cloud accounts — but the failure modes are similar.
A thorough multi-tenancy test looks for:
- Cross-tenant BOLA. Can user in tenant A retrieve, modify or delete resources belonging to tenant B by manipulating identifiers? The single highest-impact category of finding in SaaS.
- Tenant context bypass. Are there code paths (typically background jobs, scheduled tasks, admin actions or webhook handlers) that operate without tenant context and therefore can be tricked into operating across tenants?
- Shared infrastructure leakage. Caches, queues, search indexes and logging pipelines often handle data from multiple tenants. Misconfigured indexes that return cross-tenant results are routine.
- Tenant administrator scope creep. A tenant administrator should be unable to escalate to global administrator. Surprisingly often, the boundary is not enforced at the API level.
- Audit-log tenancy. Can a tenant administrator see audit log entries belonging to another tenant? This is a common quiet finding that surfaces in customer reviews rather than internal testing.
Multi-tenancy testing requires explicit scoping. It is not picked up incidentally by general application testing; it has to be requested, designed and instrumented for. Most SaaS organisations should test multi-tenant boundaries at least annually, more often if tenant isolation logic has changed.
Testing cadence that works for SaaS
A workable cadence for a typical mid-stage SaaS organisation:
- Quarterly application testing — or per-major-release, whichever is more frequent. Focused on the application and API.
- Annual cloud configuration review — IAM, networking, storage, logging, secrets and identity configuration. Reviewed against CIS Benchmarks and cloud-specific guidance.
- Annual identity infrastructure review — SSO configuration, OAuth, MFA, account recovery and session handling.
- Annual external infrastructure test — covers marketing and auxiliary services that are not the core product.
- Continuous external attack surface monitoring — between engagements, an EASM service catches newly exposed services, subdomains and certificates as they appear.
- Continuous vulnerability scanning — for hygiene and patch tracking, particularly on infrastructure and dependency layers.
- Pre-launch testing for material features — any release that touches authentication, authorisation, payment, customer data export or third-party integration warrants targeted testing before launch.
Customer-mandated tests sit alongside this programme. Enterprise B2B customers will sometimes require their own pen test of your environment as part of vendor due diligence; a well-run programme makes responding to those requests routine rather than disruptive.
Evidence enterprise customers expect
Beyond the testing itself, SaaS organisations need to be able to demonstrate the testing was meaningful. Common evidence requests:
- Penetration test summary letters. Redacted summaries from a CREST-certified or NCSC CHECK-aligned provider, suitable for sharing under NDA.
- SOC 2 Type II report. References pen testing as part of the control narrative.
- ISO 27001 certification. Annex A 8.8 expects vulnerability identification on a defined cadence.
- Remediation evidence. Customers increasingly ask not only “do you test?” but “what did you find, and what did you fix?” Be ready to discuss both at the appropriate level of detail.
Frequently asked questions
Do we need a pen test before SOC 2?
You typically need penetration testing for SOC 2 Type II if your selected control set references it, which most do. Auditors look for evidence that testing occurred at a defined cadence and that findings were tracked through to remediation.
Should we test our staging or production environment?
Production is preferred for accuracy. A representative staging environment with the same configuration as production is acceptable; a dev environment with skeleton data is not.
How should we handle customer-mandated pen tests?
Customer-mandated testing is increasingly common in enterprise B2B sales. Maintain a documented process for granting scoped access under NDA, with clear timing and reporting expectations. Treat it as a sales-enabling control.
Is application security testing the same as SaaS pen testing?
Overlapping but not identical. SaaS testing must specifically cover multi-tenancy, cloud configuration and identity infrastructure — areas a generic application test will often miss.