Penetration Testing for SaaS Providers

The test is a sales asset

For most SaaS businesses the trigger is commercial, not regulatory. An enterprise prospect's security review asks for evidence of independent penetration testing by an accredited provider within the last twelve months. Without it the deal stalls.

That changes what a good report looks like. It needs an executive summary a procurement team can read, a clear scope statement, evidence of retest and remediation, and provider accreditation they can verify. We write with that audience in mind, because it is the one that determines whether the report does its job.

The finding that matters most

Tenant isolation. In multi-tenant systems, the question is whether customer A can reach customer B's data. It fails more often than anyone expects, and it fails subtly — an API returning records filtered in the UI but not the query, a report generator scoped to the user but not the tenant, a file store keyed on predictable identifiers.

This is the single most damaging class of finding in SaaS, and automated scanning cannot find it. It requires two accounts in two tenants and someone deliberately trying.

What else we consistently find

Broken object-level authorisation in APIs — the UI enforces access, the API does not.
Admin impersonation features built for support, with no audit trail and weak controls on who can invoke them.
Webhook and integration endpoints that trust their input.
Signup and invitation flows allowing access to the wrong tenant, or privilege escalation within one.
Staging environments with production data and no access control.

Cadence and timing

Annually at minimum, and before any significant architectural change. If you are raising or entering enterprise sales, test before the diligence starts rather than during — findings discovered under deal pressure get remediated badly.

Between annual tests, continuous vulnerability scanning covers dependency drift, which is where most new exposure appears in a fast-moving codebase.

What we need from you

Two accounts in each of two separate tenants, credentials for each role, API documentation, and a staging environment that genuinely mirrors production. Grey-box testing finds substantially more per day than black-box, and withholding information does not make the test more realistic — it just means paying us to spend a day on reconnaissance.

Common questions

Will the report satisfy our enterprise customers?

That's what it's written for. It includes scope, methodology, findings with severity and evidence, remediation status and our accreditation details. CREST accreditation is independently verifiable, which is usually what security reviewers actually check.

Can we share the report with customers?

Yes, it's yours. Many SaaS companies share a summary or a letter of attestation rather than the full technical detail. We can provide a customer-facing summary alongside the full report if that's useful.

Do we need SOC 2 or ISO 27001 as well?

They answer different questions. A penetration test evidences technical security at a point in time; SOC 2 and ISO 27001 evidence process and control over a period. Enterprise buyers often want both eventually. Testing is faster and cheaper, so it usually comes first.

How long does a SaaS platform take to test?

It depends far more on the number of user roles and distinct features than on customer count or code size. Multi-tenancy, a payment flow, an API and an admin console each add real time. We'll give an honest estimate after a scoping call.

Should we test production or staging?

Staging, if it genuinely mirrors production — same code, same configuration, representative data. If it doesn't, the test result is about staging rather than about your product. Where staging has diverged we'd rather test production carefully than test something irrelevant.